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ABSTRACT 



R^ E ^N°X LIBRARY 
NAVAL POSTGRADUATE SCHnm 
monterev ca 93 9^f n C , HOOL 



Over the past decade, changes in the global power structure have driven the United 
States into a major reassessment of its force structure and global force projection 
requirements. There is a resulting need for force deployment models that offer quick, 
accurate analysis of force projection options and proposed force structure changes. One 
model, the Force Deployment Estimator (FDE), a combination discrete event simulation 
and goal program, is currently used by the J8, Warfighting Analysis Division (J8/WAD). A 
second model with similar capabilities, the Naval Postgraduate School / RAND Mobility 
Optimizer (NRMO), is a linear program that was written for the Air Force Studies and 
Analysis Agency. In order to compare the two models and give J8/WAD the option of a 
second model for use in analysis, NRMOAS (NRMO Air/Sea) was created by adding a 
sealift component to NRMO. NRMOAS creates both an air and sea network and can be run 
with the user designating the unit’s mode of travel, the model determining the same or a 
combination of both. This thesis compares the results of several different scenarios run 
through FDE and NRMOAS. In all cases tested, NRMOAS out-performed FDE in terms of 
timely delivery of personnel and cargo. Additionally, NRMOAS allows a far higher level of 
resolution in network structure. Recommendation to J8/WAD is that NRMOAS be used for 
detailed mobility analysis. Also recommend are changes to FDE to improve its usefulness. 
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EXECUTIVE SUMMARY 



Over the past decade, changes in the global power structure have driven the United 
States into a major reassessment of its force structure and global force projection requirements. 
Numerous studies have established a need for models that are flexible, and can offer quick, 
accurate analysis of force projection options and proposed force structure changes. The J-8, 
Warfighting Analysis Division (J-8/WAD)’s current tool for analyses of this nature is the Force 
Deployment Estimator (FDE), a combination discrete event simulation and goal programming 
model provided by SETA Corporation. Because FDE does not achieve optimal solutions and it 
sometimes does not complete execution, it is desirable for J-8/WAD to have a second model to 
compare against FDE. 

The Naval Postgraduate School / RAND Mobility Optimization model (NRMO), a 
linear optimization model that considers airlift only, has many similar capabilities to FDE. The 
purpose of this thesis is to make a comparison of the two and recommend to J8/WAD which 
one better suits their needs. In order for NRMO to be useful to J-8/WAD and comparable to 
FDE, it must also handle sealift. This additional capability required several augmentations to 
the existing NRMO model, which are developed in this thesis. The result is the Naval 
Postgraduate School / RAND Mobility Optimizer, Air / Sea (NRMOAS), a version of NRMO 
that allows the model to conduct both airlift and sealift operations. In order for NRMOAS to set 
up both an air and sea network, it was necessary to add sets to distinguish airfields from ports, 
aircraft from ships (referred to jointly as “vehicles”), and air ports of embarkation (APOEs) 
from seaports of embarkation (POEs). These additions also required the separation of the 
variables used to make initial allocation of vehicles. Once initially allocated, ships travel only 
on sea routes and aircraft only on air routes, so all other constraints can be used by both aircraft 
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and ships without fear of redundant or conflicting use of assets. Other changes that were 
required dealt with port capacity and fuel consumption constraints. In addition, J-8AVAD 
required that the model allow the user to track the by-day delivery of every unit’s cargo and 
personnel. This calculation was added to NRMO. Values for ship speed, capacity, load and 
unload times and fuel consumption were taken directly from FDE. Where information was 
unavailable, it was developed from military manuals, phone calls and existing data sets. 
NRMOAS operates with two types of travel mode selection: user designated and model 
designated. This required the compilation of aircraft / ship load tables that were a composite of 
those found both in NRMO (units by air only) and FDE (units by air or ship, but not both). 

Once developed, three scenarios were run through NRMOAS and FDE. FDE was 
extremely challenging to work with and demonstrated several major restrictions in its ability to 
represent an actual network. Paths with more than four links are not tolerated by the model, 
making accurate depiction of deployment networks virtually impossible. Similarly, scenarios 
with a large number of source nodes aand a small amount of cargo caused FDE to crash. 
Difficulties were also encountered building the FDE data sets. In most caes, FDE files are built 
using a legacy file which contains extensive unit and carrier information. This file serves as a 
shell from which desired scenarios are built. Building files from scratch is extremely 
challenging and is, in fact, highly discouraged by experienced FDE users. Specific problems 
include: FDE’s inability to utilize a path that has any more than four links, and FDE’s inability 
to handle a network designed with multiple source nodes and small amounts of cargo. 
Eventually, data was sent to a SETA analyst who built the closest representation of the desired 
deployment network that could be designed. Once FDE was running, no more than 26 trial 
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solutions could be requested for any problem. Any number higher than that again caused the 
model to crash. 

Once results were obtained from FDE, comparison were made between the two models. 
NRMOAS out-performed FDE in terms of timely delivery of cargo and personnel in all runs. 
Totaling the units from all three scenarios, NRMOAS delivered 67.7% of unit cargo and 65.1% 
of unit personnel on-time compared to FDE’s 44.00% for unit cargo and 41.3% for unit 
personnel. NRMOAS also achieved a high on-time delivery rate of 95.8% for unit cargo and 
100.0% for unit personnel compared to FDE’s highs of 70.8% and 80.3%, respectively. 
NRMOA’s superior performance was attributed to better utilization of assets available. 

There are two final conclusions. First, if FDE is to be retained as a tool for analysis in 
J8/WAD, it requires major improvements in its ability to accurately represent deployment 
networks. The initial allocation algorithm, the graphical user interface and the extreme 
difficulty in building files from scratch must also be addressed. The second conclusion is that 
NRMOAS ’s superior performance and higher level of resolution for networks and infrastructure 
make it a better tool for analysis than FDE. Recommendation to J8/WAD is that NRMO be 
adopted as their main tool for detailed analysis, while FDE can be used for broad brush mobility 
questions that don’t require a high degree of network resolution. 
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I. INTRODUCTION 



A. BACKGROUND 

Over the past decade, changes in the global power structure have driven the United 
States into a major reassessment of its force structure and global force projection requirements. 
The Mobility Requirements Study (MRS) of 1990, the MRS Bottom Up Review Update (MRS 
BURU) of 1992, the Quadrennial Defense Review of 1996, and numerous other smaller, more 
limited studies, have established a need for models that can offer quick, accurate analysis of 
force projection requirements and proposed force structure changes. Because these taskings can 
run the gamut from major force deployment studies of the magnitude of DESERT SHIELD / 
DESERT STORM to the effects of adding to or deleting strategic lift capabilities, the required 
models should be flexible. 

B. PROBLEM STATEMENT 

The J-8 (Force Structure, Resources and Assessment) section of the Joint Chiefs of Staff 
is often tasked with conducting these types of studies. Within the J-8, these taskings normally 
fall to the Warfighting Analysis Division (J-8/WAD). In most cases, J-8/WAD is concerned 
with the following general types of questions: 

1. How long will it take to get units and cargo to the Area of Operations? 

2. What is the most efficient use of the assets available? 

3. What is the affect of changes in specific assets? 

4. What is the affect of changes in infrastructure? 
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J-8/WAD’s current tool for analyses of this nature is the Force Deployment Estimator (FDE) 
(FDE URM, 1996), provided by SETA Corporation. FDE combines a discrete event simulation 
and goal programming model. It is used both to generate force arrival profiles and to conduct 
sensitivity analysis on the results. Because FDE does not achieve optimal solutions and it 
sometimes does not complete execution, it is desirable for J-8/WAD to have a second model to 
compare against FDE. The Naval Postgraduate School / RAND Mobility Optimization model 
(NRMO) (Melody, et al, 1997) is a linear optimization model that considers airlift only. With 
the addition of a sealift component, NRMO could offer J-8/WAD a viable alternative to FDE. 
The purpose of this thesis is to add a sealift component to NRMO, compare that model with 
FDE and make a recommendation to J-8/WAD as to which model better suits their needs. 
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II. MODEL REVIEW 



A. FORCE DEPLOYMENT ESTIMATOR 

1. Overview 

The Force Deployment Estimator (FDE) is designed to provide quick analysis of 
deployment and sustainment issues as they relate to contingency plans (FDE URM, 1998, p. 1- 
1). Specifically, it is designed to answer the following questions: 

a. Can the forces be deployed to the theater on time (as defined by the required 
delivery date)? If not, how close can they get? 

b. What are the most likely arrival times for forces? 

c. What are the most important factors contributing to the arrival times for the forces? 

d. How will the answers to the above questions change if the theater deployment is 
delayed by late availability of units or lift assets; by enemy attacks on ports or 
airfields; or by closure of vital choke points such as straits, canals, or shipping lanes 
caused by enemy minefields? (FDE URM, 1998, p. 3-1) 

FDE allows sensitivity analysis over a variety of issues. By varying input, users can 
parametrically assess a war plan with respect to variations in force structure, lift capabilities, 
phasing of units and any number of questions that arise during force structure analysis. 

2. History 

FDE 1.0 was developed by Los Alamos National Laboratory and released in April of 
1992. Originally written in FORTRAN, it underwent its first major overhaul by Potomac 
Systems Engineering and was released as FDE 2.0 in September of 1994. FDE 2.0 added 
stochastic loading time variables in an effort to make a more realistic appraisal of deployment 
requirement times. The next upgrade, FDE 3.0, was released by SETA Corporation in October 
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of 1996. FDE 3.0 is a major revision, including conversion to C++ and the addition of a 
graphical user interface. SETA also advertised that FDE 3.1 would contain a simulated 
annealing capability. This capability was supposed to yield a 5 to 20 times increase in run time 
and to provide globally optimal solutions (FDE URM, 1998, p. 3-9). FDE 3.1 was released in 
April of 1998, but did not contain the simulated annealing capability and in fact showed no 
significant difference from version 3.0. It does not provide global optima. FDE 3.1 is the 
version that will be used for comparison with NRMO. 

3. Features 

FDE’s primary function is the efficient assignment of lift platforms for deployment and 
sustainment of units, in support of war plans. Assignment of cargo to carriers and carriers to 
routes is made within the constraints set by the user. The model “solves” the problem based on 
four specific goals: 

1. Minimize closure time deviations for units. (Closure time deviation is defined 
as the number of days after the required delivery date (rdd) that a unit arrives 
in theater.) 

2. Minimize the dispersion of delivery times for each unit. (Dispersion is 
defined as the time between consecutive deliveries of a unit’s cargo and 
personnel.) 

3. Minimize the cost of the deployment. (An actual dollar value for operation of 
each type of lift asset can be added to the problem.) 

4. Minimize the number of carrier reallocations. (Lift assets are initially 
allocated at random or are assigned to specific bases by the user. They are 
“re-allocated” if they must be moved empty from one embarkation base to 
another during the execution of the simulation.) 

These goals may be used singly or in any combination, as specified by the user. If no goal is 
specified, FDE takes the first goal as the default. (FDE URM, 1998, p. 3-4) 
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FDE’s methodology can be described as a combination of discrete event simulation, goal 
programming and Monte Carlo search techniques (FDE URM, 1998, p. 3-1). The discrete event 
simulator is the portion of code that “executes” the deployment. The goal program is not an 
actual goal program, as defined in the linear programming literature [Dantzig and Thapa, 1997], 
but simply a method to check the solution to see if it meets the goals, as selected by the user. 
The simulation runs as many times as the user specifies, saves all the solutions and then picks 
the “best” one, in terms of meeting the user defined goals. The URM states that the solution 
will be a local, but not necessarily global optimum (FDE URM, 1998, p.3-6). There is no 
substantiation to this claim. 

4. Organization 

FDE is organized into three main components: a data management facility, a modeling 
kernel and a graphical user interface (FDE URM, 1998, p. 2-3). 

The data management facility is composed of a large internal data file and numerous output 
files. To operate, FDE requires input from formatted data files. These can be generated from 
the internal data file or input via the graphical user interface. The internal data file contains 
legacy files called “fort.l” files. These files have been developed over time and contain large 
amounts of data related to unit loading requirements and cargo carrier capacity. The “fort.l” 
files can be used as a starting point from which to build current data sets, with additional 
required elements input via the GUI. The ten output files are written in two formats: reports 
and graphs. Specific output file information is shown in Appendix A. (FDE URM, 1998, p. 2- 
2 ) 

The modeling kernel contains the actual mathematical algorithms used to solve the 
problem. It has three main components; the discrete event simulator, the so called goal 
programming model and a Monte Carlo simulation. 
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The discrete event simulation is the core of FDE and actually “executes” the deployment 
simulation. The simulation itself contains four major algorithms. The first algorithm makes the 
initial assignments of carriers to units. This is done in direct proportion to the tonnage 
requirements of the unit and in inverse proportion to the square of the product of the unit 
priority and required arrival date, while also considering what types of cargo the carrier can 
move. The user may over-ride this algorithm by pre-assigning carriers to specific start points or 
units. The second algorithm contains the logic which re-assigns carriers once they have 
completed their current delivery. It is similar in process to the initial assignment algorithm, so 
the carrier will be re-assigned to the node that needs it the most. (FDE URM, 1998, p. 3-16) 

The third algorithm is the aircraft loading algorithm. This algorithm considers five 
separate loading cases, based on allowable load combinations and aircraft capacity. The amount 
of personnel or cargo an aircraft can carry is determined from load factors designed by the US 
Air Force Studies and Analyses Agency for the MIDAS model (FDE URM, 1998, p. 3-16). The 
algorithm also accounts for the amount of cargo and personnel moved throughout the 
simulation. Algorithm specifics are shown in Appendix A. 

The final algorithm is the ship and rail loading algorithm. The actual logic used in this 
algorithm comes from the Carrier Payload tables in the FDE database. Once the algorithm 
determines whether the carrier in question is a ship or train, it checks to see if the cargo that is 
available to be loaded is greater than or equal to the carrier’s capacity, as measured in tons of 
cargo per unit type. If so, the carrier is loaded until full and it departs for its destination. If not, 
the carrier loads all available cargo and the model looks for any other cargo enroute to the same 
destination. If such cargo exists, the carrier waits until this cargo is delivered and loaded. If 
not, the carrier departs. (FDE URM, 1998, p. E-l) 
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The modeling kernel also contains the goal programming algorithm. What FDE calls a 
goal programming algorithm is not an actual goal program as defined in linear programming 
literature. (FDE URM, 1998, p. 3-6) In actuality, it simply takes the current solution and 
compares it against the “best” solution found to that point, in terms of meeting the user defined 
goals. If the new solution comes closer to meeting these goals, it becomes the new “best” 
solution. The URM is not specific about how this comparison takes place. Following the 
comparison, the program checks to see if the simulation should be run again, based on a user 
defined number of iterations. This continues until the required number of simulations has been 
completed. A better name for the FDE goal programming module would be a “goal evaluator”. 

The final part of the modeling kernel is the Monte Carlo simulation, which randomly 
allocates carriers to specific nodes and paths throughout the network. This is repeated at the 
start of every run of the simulation. The number of desired simulation runs is set by the user. 
SETA advertises that if the number of runs is sufficiently large (i.e. 25 to 75), the results will be 
very close to a global optimal. (FDE URM, 1998, p. 3-9) No substantiation to this statement is 
offered. This would be a unique result in the operations research literature if it were proven. 

The graphical user interface ties the data and related file utilities to the modeling kernel 
(FDE URM, 1998, p. 2-3). It is a standard Windows-based product, with five types of 
windows. The main window appears when the program is started and is the window through 
which all other windows are started and accessed. Dialog windows provide secondary interface 
with FDE and appear over the main window. File selection windows allow the user to select 
specific files from various directories and sub -directories. Selection windows are contained 
within other windows and allow the user to make selections from lists of choices contained in 
the window. Finally, message windows are used to send messages to the reader. They include 
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information dialog, question dialog, working dialog and warning dialog. (FDE URM, 1998, p. 
4-4) 

5. Hardware 

FDE was designed and tested to run on a SUN SPARC system. Currently, J-8AVAD 
runs FDE on SUN/UNIX work stations, but it can also run on stand-alone units. It requires 1.3 
gigabytes of hard disk. In addition, 300 megabytes of swap-space is recommended to allow 
FDE to build temporary matrices when solving problems, for a total requirement of 1.6 
gigabytes. FDE requires no additional software. (FDE URM, 1998, p. 2-3) 

6. Assumptions and Restrictions 

FDE’s documentation includes fourteen stated assumptions. The most critical 
assumption is that FDE is designed as an operational planning tool and not as a logistics 
planner. The logistics planning factors are sufficient to answer force deployment questions, but 
not detailed logistical questions. In particular, a high level of aggregation of unit cargo and base 
infrastructure would make FDE ineffective as a logistical planning tool. Moreover, FDE is 
designed to analyze initial deployments, defined as activity prior to the establishment of a 
logistics pipeline. During the initial phase, deploying units and sustainment requirements 
compete for assets equally. FDE assumes that once a logistics pipeline is established, 
sustainment will no longer be required to compete for assets, but will have specific assets 
dedicated to its movement (FDE URM, 1998, p. 3-2). Additional assumptions deal with 
modeling issues and are listed in Appendix A. 

J-8 imposed three restrictions on the designers of FDE. First, given a scenario and the 
input, FDE must run in under 30 minutes. (This restriction was non-specific as to the platform 
used or the number of simulation runs required.) Second, all events that take place during the 
simulation must be physically realistic. For example, a shipping route cannot cross a land mass. 
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but must navigate around it. Finally, the model must be “user-friendly”. (FDE URM, 1998, p. 

3-2) 

7. Input 

FDE categorizes scenario information into five parts, which are defined below: 

a. Lift Assets (Carriers). These are defined as those items that can transport personnel 
and/or cargo from port to port. FDE lift assets include aircraft, shipping, trucks and 
trains. Lift asset information includes average speed and capacity, broken down by 
cargo types. 

b. Deployment Requirements. These include the actual units, their equipment, 
destination, point of origin, date available to move, required delivery date and unit 
priority. 

c. Network. This is the node-arc network of routes available for the deployment. Nodes 
are defined by longitude and latitude, carrier types that can use them and carrier 
capacity. Arcs are defined by the nodes they connect and the carriers that can travel 
on them. 

d. Goals. These are defined by the user and were listed earlier. Any combination, 
including all four, can be selected. 

e. Constraints. These are derived from the scenario. They include items such as 
availability of assets or restrictions on certain carrier/cargo combinations, barriers to 
carrier/path combinations or degradation of certain nodes or arcs due to enemy 
activity. Route or node degradation is provided as user inputs. 

(FDE URM, 1998, p. 3-3) 
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* Not Implemented 

Figure 1. This flow diagram depicts the primary modules of the solution algorithm. This 
methodology is not a single program, but rather a series of three techniques that work together 
until one of three things happens: a feasible solution is achieved, the model “cut-off’ criterion is 
reached, or a specific number of solutions are generated (FDE URM, 1998, p. 3-5). 



8. Solution Method 

The solution method uses three separate mathematical techniques that interact iteratively 
(FDE URM, 1998, p.3-5). This method is pictured in Figure 1. When solving the problem, 
FDE first determines if there is a feasible solution to the allocation of lift to satisfy all the goals. 
If not, FDE will allocate assets to achieve a solution that is as close to feasible as possible, i.e. 
the “best” possible solution (FDE URM, 1998, p. 3-1). FDE can be used in either a simple or a 
variable mode. 
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The simple mode is the most commonly used. Input values such as speed, carrier 
capacity, etc. are fixed at their expected value. The program runs a user defined number of 
trials and the solution which comes closest to meeting the user defined goals is given. Simple 
mode is normally used when trying to answer the question, “Can forces be deployed to the 
theater on time?” or “What is the most likely theater deployment time?” (FDE URM, 1998, p. 
3-10) 

In the variable mode, the user chooses both the number of simulation runs and the 
number of trials within each run. First, the model finds a run’s “best” solution. Then it 
conducts sensitivity analysis on this solution by drawing a value for each variable from a given 
probability distribution and running the solution with that data. This “draw and solve” cycle is 
repeated for whatever number of trials the user chooses. The model then performs an Analysis 
of Variance (ANOVA) on these results and gives each solution’s mean, variance and most 
likely result. FDE URM, 1998, p. 3-11) 

9. Results 

Results from FDE can be used either in a report or graphical format. FDE’s results are 
most commonly used to answer the four questions that were stated at the beginning of the 
section on FDE. In addition, sensitivity analysis can easily be carried out by varying input 
parameters and observing how that changes results. Analysis of this type can then be used to 
gain insight into force structure questions from a force deployment standpoint. For example, 
questions such as increasing or decreasing the number of a certain type of carrier or heavy 
versus light divisions can be considered with an eye towards their effect on the United States’ 
ability to deploy its forces abroad with a given fleet of lift assets. FDE can also be used to 
“wargame” deployment plans and determine how the loss or addition of assets will affect these 
plans. 
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B. NAVAL POSTGRADUATE SCHOOL / RAND MOBILITY OPTIMIZER 

(NRMO) 

1. Overview 

NRMO was designed to help planners and analysts answer the airlift force structure and 
infrastructure questions that are associated with force deployment issues. Typical of these types 
of questions are: 

a. Are the given fleet and infrastructure assets adequate for deployment? 

b. Where are the system bottlenecks? When do they matter? How much do they limit 
airlift capacity? 

c. What changes in mobility concepts of operation would improve performance? What 
about the affects of reduced closure time (defined as the arrival of a unit’s personnel 
and cargo) or reduced resource expenditures? 

d. How do the results differ across scenarios? 

(Melody, et al., 1997, p. v) 

NRMO has been used to conduct airlift force structure analysis, infrastructure analysis and 
concept of operations analysis using a single model. 

2. History and Genealogy 

Development of NRMO began in May of 1996 as a cooperation between the Naval 
Postgraduate School (NPS) and RAND. At that time, NPS was under contract to the Air Force 
Studies and Analysis Agency (AFSAA) for work in the area of air mobility. RAND, who had 
previously done a significant amount of research in this field, began their portion of the work in 
response to a direct-assistance request from Headquarters, United States Air Force. AFSAA 
desired that NPS and RAND work together in an attempt to create a single optimization model 
that incorporated all the best features of past models. NRMO was the result. The current model 
is under the cognizance of the Air Force Studies and Analysis Agency (AFSAA). In addition to 
continuing research being done by NPS and RAND, other users include Air Mobility 
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Command; Air Force Institute of Technology; J-8/Warfighting Analysis Division, JCS; U.S. 
Air Force Academy; University of Texas at Austin; and Washington University, St. Louis. 

NRMO can trace its lineage to four main models; Mobility Optimization Model (MOM) 
(Wing, et al, 1991), THRUPUT1 (Yost, 1994), CONOP (Killingsworth and Melody, 1997), and 
THRUPUT2 (Morton, et al, 1996). MOM, developed by J-8 and NPS, incorporated both sealift 
and airlift in a time-dynamic model with a simple geographical network representation. 
THRUPUT1, developed in 1991 by AFSAA had an extensive geographical network, but was a 
steady state model. THRUPUT2, developed by NPS for AFSAA in 1994-5, combined the 
dynamics of MOM and the extensive geographic representation of THRUPUT1 into a single 
model. CONOP, developed by RAND in 1994, is a time-dynamic model with a robust 
geographical representation much like THRUPUT2 and with features to handle intra-theater 
cargo lift and aerial refueling. CONOP was used to address force deployment policies relating 
to tanker aircraft and C-17 usage. NRMO, while developed and written from scratch, merged 
many of the techniques developed in the above mentioned models. (Melody, et al, 1997, p. 5) 
NRMO and its progenitors are all implemented with the Generalized Algebraic Modeling 
System (GAMS). [Brooke, Kendrick and Meeraus, 1988.] 

3. Features 

NRMO is a linear program. The objective function’s primary purpose is to maximize 
on-time deliveries, air-asset measures of performance and ground assets measures of 
perfromance (Melody, et al., 1997, p.12). Mathematically, this is done through the 
minimization of the weighted sum of late and undelivered cargo penalties, subject to restrictions 
such as aircraft balance, aircraft payload, and airfield capacity (Baker, 1997, p. 55). There are 
secondary terms in the objective function, relating to preservation of assets, used to break ties 
among alternate optima with respect to the primary purpose. It can have up to twenty-seven 
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types of decision variables, which it uses to allocate aircraft and crews among various allowable 
options defined in terms of load carried, route and method of delivery. 

NRMO’s many features can be used to represent the complexities of an air mobility 
network (Melody, et al, 1997, p.10). NRMO’s network representation allows for multiple 
embarkation, debarkation and enroute airfields, to include use of recovery bases (bases where 
aircraft are serviced following a quick turn-around mission). NRMO has the ability to add 
aircraft during the deployment period in order to simulate the mobilization of assets, such as 
Civilian Reserve Air Fleet (CRAF). Aircraft can be utilized in dual roles (ie. KC-lO’s can carry 
cargo or perform aerial re-fueling) and can, if needed, change roles during the execution of the 
model. In addition to inter-theater movement, NRMO can move cargo via intra-theater shuttles. 
NRMO also has the ability to track the movement of individual Time Phased Force Deployment 
Data (TPFDD) line numbers. (Melody, et al, 1997, p. 10) 
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4. Organization 

NRMO consists of a GAMS formulation, five input files and an output report. The 
actual GAMS code for the original NRMO is not reproduced in this paper, but the conceptual 
formulation is shown in Figure 2: 



Maximize: On-time Deliveries 




+ air assets measure of performance 


+ ground assets measure of performance 


Subject to: 

Meet time-phased demands: 


by line id, cargo type 


Aircraft Allocation/balance: 


by type, airfield, for 


strategic, 


tanker, and tactical 


missions 




Cargo Transshipment balance: 
time 


by line id, cargo type. 


Cargo/passenger capacity: 


by line id, aircraft type, 


time 




Aircraft utilization rates: 


by aircraft type, time 



Figure 2. Conceptual Formulation for NRMO. Although the conceptual formulization calls for 
maximization, this is actually accomplished by minimizing the weighted sum of late and 
undelivered cargo penalties (Melody, et al, 1997, p. 12) 

NRMO’s five input files contain all the information required for NRMO to solve the 
problem. Their contents are detailed in Appendix B. NRMO’s output file is designed to be 
read as comma-delineated input to a spreadsheet. Its contents are also detailed in Appendix B. 

5. Software 

NRMO uses the Generalized Algebraic Modeling System (GAMS) [Brooke, et al, 
1988]. GAMS is a commercial programming language specialized for linear, integer and non- 
linear programming. It is designed to allow models to be solved on many different types of 
computers with no formulation changes. GAMS requires no special editor or graphical user 
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interface, but instead can be written using any word processor. Hardware specifications call for 
2MB RAM and 200KB Real Mode Memory to run GAMS, however an average sized NRMO 
scenario (single MTW) normally requires 250 to 300 megabytes of memory. Depending on the 
type of problem being solved, a GAMS user can choose from multiple solvers, seven of which 
can solve linear programming problems. 

6. Input 

NRMO works in accordance with user-set delivery windows, defined in the input files 
by available-to-load dates, required delivery dates and maximum allowable late dates. While 
specific inputs will obviously vary from scenario to scenario, the following generic information 
is needed for NRMO to run a scenario: 

a. Unit Movement Requirements: available-to-load dates, required delivery dates, 
commodity codes (a standard description of generic unit types that lets planners know 
how much of a certain type of a specific unit’s cargo an aircraft can carry), and the actual 
number of passengers, and tons and types of cargo that need to be moved. 

b. Route Data: bases and aircraft/route compatibility. 

c. Base Data: location, MOG capacity, and specific use plans (off-load, recovery, tanker 
bed down, etc.) 

d. Fleet Availability Data, by day. 

e. Aircraft Data: speed, fuel consumption and payload. 
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7. 



Solution Method 



NRMO’s objective combines penalties for violating delivery schedules or cargo 
demands with penalties for actions that are wasteful or disrupt the smooth flow of operations. 
The major penalties are associated with personnel and cargo that are delivered late or not 
delivered at all. Secondary penalties are incurred for deadheading crews or for reassignment of 
aircraft from cargo to aerial refueling duties or vice versa. Finally, a reward can be earned for 
resting aircrews at bases that are embarkation nodes. 

Optimization is done subject to the constraints shown in the conceptual formulation. 
The actual mathematical algorithms used to solve the problem will depend on the choice of 
solver. (Melody, et al, 1997, p. 33) 

8. Results 

Results from NRMO are applicable to analysis of airlift force structure, infrastructure 
and concepts of operations. Because the model uses available assets in the most efficient 
manner, shortfalls in meeting deployment requirements indicate a shortage of capability vice an 
inefficient scheduling heuristic (Melody, et al, 1997, p. 14). Airlift force structure sensitivity 
analysis can be accomplished by varying input data. Additional airlift force structure questions 
can also be answered through minor changes to the objective function. One example of this 
would be to let the initial aircraft inventory vary at a cost, so NRMO can “buy” the aircraft it 
needs to complete the mission. Similar analysis can be done on base infrastructure. Bases that 
are constrained by aircraft parking or fuel available can be quickly identified. This could 
answer the question of which bases would benefit most from augmentation of expeditionary 
airfield assets. Insight into questions like these can also be gained using the marginal values on 
constraints in the GAMS output. 
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c. 



MOBILITY OPTIMIZATION MODEL (MOM) 



1. Overview 

Of the mobility models in NRMO’s direct genealogy, the only one that included both air 
and sea components was the Mobility Optimization Model (MOM). MOM was developed to 
support the Mobility Requirements Study (MRS), that was mandated by Congress in the 
National Defense Authorization Act for Fiscal Year 1991. The purpose of MRS was to provide 
Congress with a plan for force projection in the 21 st Century. During the course of MRS, it 
became evident that no adequate models for analysis of lift assets required to deploy forces were 
available. While some models could be used to identify shortfalls in capabilities, none could be 
used to identify how to overcome them. (Wing, et al, 1991, p. 2) 

MOM was designed to solve two problems. The first (Phase I of the model), was to 
determine the minimum cost mix of lift assets needed to achieve on time delivery and 
sustainment of forces. The second (Phase II of the model) was to determine what affect an 
inadequate mix of assets would have on on-time delivery for a deployment. Used together, this 
would allow planners to find an optimal lift mix based on a most likely scenario (Phase I) and 
then see how it, or a less optimal mix, would work for other possible scenarios (Phase II) 
(Wing, et al, 1991, p. 3). MOM was modeled as a multi-commodity network flow problem, 
designed to be solved by linear programming. It was implemented in GAMS on a personal 
computer (Wing, et al, 1991, p. 20). 

2. Organization 

The formulation for MOM Phase I has five parts; the inventory problem, demand 
satisfaction, air and sea throughput constraints, land and sea-based prepositioning and the 
objective function (Wing, et al, 1991, p. 5). The inventory problem is defined as what assets are 
available for each mission on a daily basis. Constraints on this problem come from lift asset 
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allocation and cycle time, with cycle time being the total time a lift asset requires to load, transit 
to the theater, off-load and return to the U.S. To simplify this process, MOM aggregated all 
U.S. bases into a single source node and all terminal destinations into a single sink node (Wing, 
et al, 1991, p 6). This gave reasonable approximations for airlift, but required the addition of 
delay variables for sealift, based on the fact that most men and equipment that require sea- 
transportation must be moved from home base to their POE and from their POD to their 
eventual destination. 

Demand satisfaction means that the capacities of the lift assets multiplied by the number 
of lifts, summed over all lift assets during the allowed period to move a given unit, must equal 
the unit requirement for that commodity (Wing, et al, 1991, p 8). Demand satisfaction 
constraints ensure that the lift asset’s capabilities, multiplied by the number of lifts and summed 
over all assets, equals the unit requirement for each commodity. Constraints are repeated for all 
types of cargo. This process was again simplified through aggregation, which was done across 
cargo categories using unit composition and lift asset capability. MOM then used a weighted 
average capacity for each lift asset, given the type of unit that was to be moved. (Wing, et al, 
1991, p. 8) 

Air and sea throughput constraints simply impose limits on the number of aircraft and 
ships that can arrive in theater, based on theater capacity. This constraint was not imposed on 
the Continental United States (CONUS), as it was felt the port and airfield system in the U.S. 
had a large enough capacity that limitations would not be a factor. (Wing, et al, 1991, p. 10) 

Prepositioning was handled by MOM as either an input or a decision variable. MOM 
accounted for the increased efficiency in the careful loading of prepositioned equipment vice the 
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more hasty loading performed during a crisis, and also allowed for the return of ships to regular 
sea-lift duties once their prepositioned cargo had been delivered. (Wing, et al, 1991, p. 10) 

The Phase I objective function minimized the sum of the cost of new lift assets and 
prepositioning assets. This allowed Phase I to answer the question of what was the minimum 
cost and asset mix to ensure delivery and sustainment of forces throughout a given scenario. 

Phase II of MOM was designed to determine the best delivery schedule that an 
inadequate force of lift assets could make. Penalties were assessed for late or undelivered cargo 
and the objective function sought to minimize these penalties. 

3. Strengths and Limitations 

MOM’s strength was not only that it considered air and sealift, but also the 
prepositioning of cargo. The inclusion of prepositioning was especially useful, as this was the 
first model that included use of prepositioning as a strategic lift option (Wing, et al, 1991, p. 
20). Another strength was the capability to model sustainment demand. MOM kept a count of 
the number of troops in theater and based the demand requirements on that number. One of 
MOM’s perceived limitations was its high level of aggregation (Wing, et al, 1991, p. 21). 
Simplicity of the model was traded for model resolution. In addition to the aggregation of bases 
and cargo types, combat units were deployed at the brigade, group and corps levels. In reality, 
since MOM was designed to forecast the lift assets needed to complete a major deployment, this 
level of aggregation was appropriate. A second perceived limitation is the fact that MOM is 
scenario dependent (Wing, et al, 1991, p. 270). Any change in the scenario requires an 
equivalent change in data, which makes the analysis of different scenarios somewhat 
cumbersome. This “limitation”, however, is certainly not unique to MOM. Many of the ideas 
from MOM were incorporated into NRMO, as will be seen later. 
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D. MODEL FOR INTERTHEATER DEPLOYMENT BY AIR AND SEA (MIDAS) 



1. Overview 

Another model that considers both air and sea components, and is still in use, is the 
Model for Intertheater Deployment by Air and Sea (MEDAS) (MEDAS UM, 1997). MEDAS 
was developed by the General Research Corporation (GRC) for the Projection of Forces 
Division of the Office of the Director of Program Analysis and Evaluation, within the Office of 
the Secretary of Defense [OD(PA&E)(PF)] (MIDAS UM, 1997, p. 1-3). MIDAS is a strategic 
deployment model that is used to analyze airlift, sealift and prepositioning options and can be 
operated as an integrated part of other systems or as a stand alone model. The current version, 
MIDAS 2.5, is written in C++ and runs on Sun workstations. 

2. Data Management 

The input data for MIDAS is similar to other models. There are three required input 
files, as well as additional files that can be used as appropriate. As with FDE, MIDAS files 
generally use a high level of aggregation; for example, the entire CONUS may be modeled as 
having only West Coast, East Coast and Gulf ports (Schank, et al, 1991, p. 61). 

MIDAS output can include up to seven separate reports, covering ship and aircraft usage 
and movement, port and airfield throughput, load efficiency, and excesses and shortfalls of 
delivery of personnel and cargo. Because these reports are not available until the completion of 
the simulation, MIDAS also writes a stream of output while it executes. This output allows the 
user to follow the simulation throughout the execution. (MIDAS UM, 1997, p. 5-1) 

3. Methodology 

MIDAS uses heuristic scheduling algorithms to select modes of deployment for 
personnel and cargo, with the goal of finding a satisfactory, rather than optimal solution. 
MIDAS considers five deployment objectives: 
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1. Efficient use of airlift and sealift transportation resources. 

2. Timely delivery of forces. 

3. Arrival of forces in sequential order, as defined by required delivery date (RDD). 

4. Arrival of supplies in time to sustain already deployed forces. 

5. Preservation of unit integrity. 

MIDAS ranks these objectives in the order shown and will work to achieve the higher 
priority objectives at the expense of the lower (MED AS UM, 1997, p. 2-1). While the ordering 
of these objectives is certainly reasonable in the sense of what MIDAS is used to analyze, from 
a real world viewpoint it seems unlikely that any commander would be willing to trade the 
efficient use of assets for the timely delivery of his forces. 

MIDAS uses an adaptive scheduling approach. Once the deployment problem is solved, 
MIDAS executes that solution. After a period of time, MIDAS builds a new problem based on 
an updated status of resources, then solves and executes the new problem. This process is 
repeated until the deployment is complete. (MIDAS UM, 1997, p. 2-3) 

Actual scheduling of assets is done by using the RDD’s. Unlike other models, however, 
MIDAS does not schedule movements to meet RDD’s, but rather uses the RDD’s to set 
priorities. Cargo is then assigned to the mode of transportation that will get it to its destination 
in the shortest amount of time. Mode assignment can be changed as the scenario develops, i.e. 
if a faster type of transportation becomes available before a load of cargo is underway, MIDAS 
will re-schedule the cargo to load on the faster asset. (MIDAS, UM, 1997, p. 2-2) 

4. Scheduling Heuristics 

When ships are mobilized, they are assigned to a port of embarkation. As cargo 
becomes available for loading at that port, MIDAS looks at empty ships, ships that are currently 
loading and ships that are scheduled to load in the future. Also considered is the minimum 
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amount of cargo that a ship must carry before it will go to a port of debarkation. A ship that 
meets the minimum load requirement, can load all the given cargo and can deliver that cargo by 
the earliest date is selected and loaded. Partially loaded ships are given preference over empty 
ships. (MIDAS UM, 1997, p. 2-5) 

Aircraft loading is accomplished in the same way, within constraints on aircraft 
productivity and airfield throughput. Also critical is the selection of aircraft routes. Viable 
routes are determined using the range-payload data of the aircraft, which shows how far an 
aircraft can fly based on what payload it is carrying. MIDAS ranks all possible routes using 
flow rates, which are determined by dividing the payload of the aircraft by the time required to 
complete the mission. The route with the most favorable (lowest) flow rate is considered the 
“best” route. If, however, the best route is not available and an alternate route that adds less 
than one day of travel is available, the alternate route will be chosen. (MIDAS UM, 1997, p. 2- 
5) 

5. Sustainment and Logistics 

Like MOM, MIDAS also has the capability to dynamically generate sustainment 
demands for the deploying units. MIDAS tracks the daily inventory of each type of sustainment 
in the supply pipeline. As the deployment is executed, MIDAS calculates sustainment demand, 
based on consumption rates and the number of personnel in theater. If demand cannot be 
satisfied by present inventory, a sustainment requirement will be generated. These requirements 
are normally delivered by ship; however, if current stocks are exhausted and demand cannot be 
meet by sealift, the sustainment requirements will be moved by air. This is commonly referred 
to as a “greedy” or “myopic” heuristic. 
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III. CHANGES TO NAVAL POSTGRADUATE SCHOOL / RAND MOBILITY 

OPTIMIZER (NRMO) 



A. METHODOLOGY 

NRMO was written strictly as an airlift model. In order for it to be useful to J-8AVAD 
and comparable to FDE, however, it must also handle sealift. This additional capability 
required several augmentations to the existing NRMO model. In all cases, changes mimicked 
existing code in order to minimally affect the initial model. The result is the Naval 
Postgraduate School / RAND Mobility Optimizer, Air / Sea (NRMOAS), a version of NRMO 
with the necessary additions to allow the model to conduct both airlift and sealift operations. 
These additions mainly took the form of the additional sets required to allow NRMOAS to 
construct two networks: one for aircraft and one for ships. The two networks then required the 
addition of two sealift-only constraints, where a single joint constraint would not function 
logically. Finally, additions were made to the output report to accommodate a J-8 specific 
requirement. All changes are detailed in the remainder of the chapter. The full mathematical 
formulation for NRMOAS is also included. 

B. ADDITIONAL SETS AND CONSTRAINTS 

NRMO has the ability to represent an extensive and complicated air network. In order 
to allow NRMOAS to set up both an air and sea network, it was necessary to add sets to 
distinguish airfields from ports, aircraft from ships (referred to jointly as “vehicles”), and 
airports of embarkation (APOEs) from seaports of embarkation (SPOEs). These additions also 
required the separation of the variables used to make initial allocation of vehicles to 
embarkation nodes, thus ensuring that ships were not sent to APOEs and aircraft were not sent 
to POEs. Once initially allocated, ships travel only on sea routes and aircraft only on air routes. 
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so all other constraints can be used by both aircraft and ships without fear of redundant or 
conflicting use of assets. 

Other changes that were required dealt with port capacity and fuel consumption 
constraints. NRMO uses the concept of maximum aircraft on ground (MOG) to determine 
airfield capacity. MOG is defined as the number of aircraft that an airfield can simultaneously 
service. It is calculated as a function of available aircraft parking spaces multiplied by an 
efficiency factor that reflects available airfield services and approximates the effects of 
congestion (queueing). (Goggins, Sept, 1995) NRMO uses two sizes of aircraft to calculate 
aircraft parking; narrow body (nb) and wide body (wb). All calculations use narrow body 
aircraft as the base. Similar to MOG, port berthing capacity is based on ship length, so when 
calculating port berthing, NRMOAS uses a similar simplified size comparison for ships. Small 
ships (ss) are defined as 800 feet or under in length, and large ships (Is) are defined as over 800 
feet in length. The equations which calculate ship berthing and aircraft parking are then simply 
mirrors of each other. This leaves NRMOAS with two similar sets of capacity constraints, 
MOG for aircraft and port capacity for ships. In the case of an air / sea aggregate base, these 
separate calculations allow the MOG constraint to account for both aircraft parking and ship 
berthing without allowing either vehicle to use the other’s available parking. 

C. CHANGES TO OUTPUT FILE 

One J-8AVAD requirement was that the model allow the user to track the by-day 
delivery of every unit’s cargo and personnel. NRMO did not include this data in its output file. 
The addition of a parameter to calculate this value, and an additional loop in the output 
generator to print the results easily accomplished this and also demonstrated the versatility of 
the output generator in accommodating user needs. In addition, a set was added to allow the 
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user to assign unit designators to line entries on the TPFDD. This makes the delivery reports 
easier to use when tracking unit deliveries. It is important to note that the addition of actual unit 
designations to deployment routes makes the data set used classified. 

D. DATA COLLECTION 

The biggest challenge to adding a sealift component to NRMO was collecting and 
inputting the data needed to allow NRMO to use ships. Every effort was made to draw data 
from FDE’s database, so as to give a more valid comparison. Since NRMO’s aircraft data was 
very complete, the main challenge lay in collecting and verifying the ship data. The Military 
Sealift Command (MSC), when fully mobilized, has access to 1066 ships, under both U.S. and 
allied registry. As with aircraft, the vast degree of variability from ship to ship makes a high 
degree of aggregation desirable. FDE uses five composite ship types. These ship types and 
their definitions are shown below and were used in NRMOAS. 

Breakbulk (BB) - Ships in which cargo is loaded in holds 

Fast Sealift (FSL) - Converted container ships. They are the largest and fastest 

ships in the strategic sealift force. Their mission is rapid transport 
of Army unit equipment 

Lighter Aboard Ship (LASH) - Carries barges that are floated aboard and stacked 
in slots. Similar in concept to stacking bakery trays in large 
metal rack. 

Roll On/ Roll Off (RORO) - Allow vehicles to “Roll On” and “Roll Off’ 

Large Medium Speed RORO (LMSR) - Self Explanatory 
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Values for ship speed, capacity, load and unload times and fuel consumption were taken 
directly from FDE. Where information was unavailable, it was developed from military 
manuals, phone calls and existing data sets. Additional data also had to be collected for the load 
capacities of various aircraft and ships. A vehicle’s load capacity varies from unit to unit. The 
differences are most noticeable with over-sized and out-sized cargo, which are more limited by 
cubic size than by weight. NRMO’s load capacity tables dealt only with aircraft. Similarly, 
FDE’s capacity tables, while dealing with both aircraft and ships, were divided so that some 
units went solely by air and others went solely by sea (with the exception of personnel, which 
always travel by air). To allow NRMOAS the ability to send units by air or by sea (see section 
on Mode selection), load capacity tables were formed as a composite of those found both in 
NRMO and FDE. These composite tables were not used in every model run, as will be 
explained in the chapter dealing with the model comparisons. 

E. MODE SELECTION 

NRMOAS operates with two types of travel mode selection; user designated and model 
designated. If the user desires to designate the mode of travel for a a unit, he or she simply 
designates that unit’s embarkation node as an APOE or a POE. For example, if Dover Air 
Force Base is designated as an APOE, any unit embarking from there can only travel by air. If, 
however, a user wants NRMOAS to decide the most efficient mode of travel for a unit, the user 
must designate that unit’s origin as both an APOE and a POE. This requires the creation of air / 
sea aggregate bases, that can accommodate both aircraft and ships. For example, a unit could 
depart from a North Carolina Air / Sea base that aggregates Pope Air Force Base and the port 
of Wilmington. NRMOAS would then determine whether the unit travels by air, sea, or a 
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combination of both. NRMOAS can also be used in a combined fashion, where the user 
designates the mode for some units and the model determines the mode for the others. 



F. NRMOAS FORMULATION 

(Note: This formulation is adapted from the NRMO formulation found in the reference 
Melody, et al, 1997. Much of the formulation is reproduced with no change. Sets that have 
been added and constraints that were altered for NRMOAS are noted in bold type.) 

Indices 



a vehicle type 

b base 

c - cargo type 

i line id 

r route 

t time period 

Note: In some cases, subscripts other than indices are used to indicate subsets. 
Sets 



T time periods 

TWi delivery time window for line id i 

T u set of time periods associated with a ute rate constraint block, u 

FT flow time periods, f = { 1,..., maximum mission time} 

U utilization rate enforcement blocks 

I line id’s 

Ifob subset of line id’s whose destination is a FOB 

hpd = 1/1 fob subset of line id’s whose destination is a APOD 

lb ,dst subset of line id’s that have base b (FOB or APOD) as a destination 

h.tm subset of line id’s that have base a (an APOD) as a transhippment point 

lb.sup subset of line id’s whose destination is in the theater belonging to super node sup 

C cargo types (bulk, over, out, pax} 

CC cargo types {bulk, over, out} 

C a subset of cargo types that can be carried by vehicle type a 

A set of vehicle types 

Aacft subset of vehicle types that are aircraft 

A c subset of vehicle types that can carry cargo type c 

A mix subset of vehicle types that can carry pax and at least one other cargo 

type {bulk, over, out} 

Apax subset of vehicle types that can carry passengers 

A S hip subset of vehicle types that are ships 
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Atkr 

Arfl 

A c hp 

B 


subset of tanker aircraft types 

subset of vehicle types that can be refueled by a tanker 
subset of vehicles that can be “chopped” 

set of all “bases” (APOE,APOD,FOB,super,enroute,waypoint,beddown, 
aerial refueling points or ports) 


Bsup 

B a f 

Bport 

B e 

Bapoe 

Bspoe 

Barp 

B t kr 

BS rec 

Bway 

BSbd wn 

BSb.sup 

BAb t tkr 

BTb,arp 

B C nv 


subset of bases that are supemodes 

subset of bases that are airfields 

subset of bases that are ports 

subset of bases that are embarkation nodes 

subset of embarkation nodes that are air embarkation nodes 

subset of embarkation nodes that are sea embarkation nodes 

subset of bases that are AR points 

subset of bases that are beddown bases for tankers 

set of super nodes that have at least one recovery base 

set of bases that are enroute navigational waypoints 

set of super nodes that have b as a shuttle beddown node 

set of FOB’S that call b their super node plus the super node itself 

subset of B arp that are served by b e B, kr 

subset of Btkr that serve b e B sup 

crew stage bases 



Routes 



R 

RD 

RB 

RBrec 

RD b 


set of all routes 

subset of routes that are delivery routes 
subset of routes that are backchannel routes 
subset of backchannel routes that include a recovery base 
delivery routes that use base b (terminal node is a super, not FOB 
or APOD) 


BDia,dir 

delivery 

RB a b 

RDb.div 

RB^div 

Bb,ori 

Rb.dst 


subset of routes that can be traveled by a vehicle of type a and carry i for direct 

subset of backchannel routes that use b and can be traveled by a vehicle of type a 

set of delivery routes that have b as a divert base 

same for backchannel routes 

routes whose origin is base b 

routes whose destination is base b 


Data 





Mission time data 



rtrv ar 

trV ar 

retrv abr 

etrv ab r 


total travel time for vehicle a to travel on route r (periods) 
rounded rtrv ar (integer periods) 

travel time for vehicle a to reach base b when traveling route r (periods) 
rounded retrv a br (integer periods) 
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maxtrv a 

msntime ar f 



flttime a rf 

gtime abr 

qtime a br 

ctrvabr 

cttrv ab 

dhtrvbb 

rttrvab 

ttrv a b 

tkrtimeabb' 

tkrrate a bb' 

shutrate a i 

gtrvi 

shuttime xa 



maximum travel time along any route for vehicle a (integer periods) 
time flown / periods into a mission (hours), where /is a time period used to 
calculate flight hours 

• hrsper if rtrv ar >/(mission continues throughout its/th period) 

• 0 if rtrv ar <f-l (mission terminates before its/th period) 

• hrsper ■ ( rtrv ar - (f- 1)) if/-l < rtrv ar < /(mission terminates during its/th 
period) 

same as msntime ar f, but only includes actual travel time, thus, 
flttime a rf < msntime ar f, since all missions have some ground or 
port delay time 

ground or port delay time for vehicle a at base b when traveling route 
r (hrs) 

offload time for vehicle a at base b when traveling route r when recovery 
used (hrs) 

travel time to b, plus crew rest, for a along r (integer periods) 
ttrvab plus crew rest (integer periods) 

travel time for deadheading crew from b 'to b (integer periods) 
tanker a reposition time (approx 2 days) from embarkation or beddown 
base b to cloud 

rounded rttrv abr (integer periods) 

in-flight time for tanker a flying from b to b 'and back (UTE) (hrs) 
maximum number of in-theater shutles per aircraft per period 
maximum number of in-theater shuttles per aircraft per period 
in-theater ground travel time for i (periods) 
shuttle travel time (for UTE) (hrs) 



Vehicle data 



newvat 

cum at 

crewrata 

purecapiac 



maxpaxo 

paxfrac a 

mngefaciar 

restrewa 

usepen a 

dhpen a 

tkrpropabb’ 



dpct a 

urate a 

initchopab 



number of new vehicles of type a available in period t 
= Ze<t newvar 

ratio of available crews to vehicle a 

number of stons of unit f s cargo of type c that can be loaded on 
vehicle type a 

maximum number of pax that can be loaded on vehicle type a 
fraction of a vehicle’s capacity that can be loaded with pax 
fraction of vehicle available for loading when flying route r for line id i 
unit reward for resting vehicle at base b e B e 
( maxi C {purecapiac} • latepen, ■ 0.01) 
usage penalty for theater aircraft and tanker reassignments 
penalty for deadheading crews 

proprotion of a full tanker consumed by aircraft a refueling at AR b on r 
(KC10 equiv) 

fraction of AR attempts by aircraft a (the one getting the fuel) that fail 
number of hours per day that vehicle a can operate 
initial vehicles chopped to theater 
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Movement requirements data 



rdd, 
dertiic 
latepen , 
maxlate, 
nogopen , 



required delivery date 

stons of demand for line id i of type c 

late delivery penalty for i per day per ston 

maximum number of time periods late delivery for line id i can arrive 
non-delivery penalty per ston ( > latepetii ■ maxlate , ) 



Other data and notational conventions 



hrsper 


number of hours per period 


acpkg a b 


unit MOG consumption of vehicle a at base b 


mogeffb 


MOG efficiency at b 


mogb 


base capacity; service spot hours per period at b 


K-) 


1 if argument is true; 0 otherwise 


(x) + 


= max{0,x } 


S 


complement of a generic set S 



In general, constraints and variables indexed by t are assumed to exist only for the appropriate 
combinations of t with those other indices. 

DECISION VARIABLES (all non-negative) 

Vehicle mission variables 



XDjar, 

XT, an 

XDRj an 

XTRiart 

xs iat 

Yan 

TKRAabbt 



# of vehicles a direct delivering i on route r departing at time t 

# of vehicles a delivering a transshipment load of i on route r departing 
at time t 

# of vehicles a direct delivering i on quick route r departing at time t 

# of vehicles a delivering a transshipment load of i on quick turn route r 
departing at time t 

# of (Round trip) shuttle missions by vehicle a delivering / in t 

# of vehicle a recovering on route r departing at t 

# of tanker sorties of type a flown from b e B,k r to b ’ e B arp in t 



Vehicles inventory variables 



RONAPOE abt 

RONPOEabt 

RONTabt 

RONR a bt 

IRONRab 

IRONR a b 

THCHOP a b, 

THCHOPRabt 



# of aircraft a remaining over night at b eB e mt 

# of ships a remaining over night at b eB e '\nt 

# of vehicles a “RONing” without recovery in t 

# of vehicles a “RONing” with recovery in t 

# of vehicles a initially assigned to b (non-recovery) 

# of vehicles a initially assigned to b (recovery) 

# of vehicles a assigned to super b's shuttle fleet from 
non-recovery routes in t 

# of vehicles a assigned to super b’s shuttle fleet from 
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TKRBabt 


recovery routes in t 

# of tankers a whose beddown base is b € B, kr in t 



Vehicles changing roles 



ALLOCACFTabt 

ALLOCSHIPabt 

TKRECabt 


# of new aircraft allocated to b e B apoe in t 

# of new ships allocated to b e B poe in t 

# of tankers a leaving b e B e \n t for service as a 
re-fueler (for cloud) 


TKRCEabt 


# of tankers a leaving tanker fleet (cloud) in t for b e B e 
for cargo hauling 


TKRBCabt 


# of tankers a assigned a super b' s shuttle fleet from 
non-recovery routes 


TKRCBabt 


# of tankers a being reassigned (from cloud) in tto b e B e 
for refueling 



Cargo 



DTONStac 

TTONSiad 


stons of i ’s cargo of type c direct delivered by a that will arrive in t 
stons of f s cargo of type c for transshipment by a arriving at 
(the transshipment node) in t 


STONSi act 

GTONSia 

NOGOi C 


stons of Fs cargo of type c shuttled by a in t 

stons of i’s cargo of type c ground that will arrive at the FOB in t 

stons of Fs cargo of type c not delivered 


Crews 

SCREWSab, 


# of crews available (rested) for a at b e B crw at the beginning 
of time t 


DHCREWSabbt 


# of deadheadiing crews for a leaving b’ at time t for 
reassignment to b 
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OBJ: Objective Function 



E E E E latepen, ■ (t - rdd l f ■ DTONS iact 

iel aeA ceC a /e7W ( 

+ E EE E • (t-rddif • STONS iact 

iel f 0 b aeAceC a teTW i 

+ E E E nogopetii ■ (t-rddif ■ GTONS ict 

l£ l fob CG C t&TWj 

+ E E nogopetii ' NOGO ic 
iel ceC 

+ E EE usepen a • \THCOP abt + THCHOPR abt ] 
beB SU p t^zT 

+ X X X usepen a • TKREC abt + X XX usepen a * TKRBC abt 

ci^Athr b e B e teT a^A^ b^B t ^ r teT 

“XXX redrew* • ( RONAPOE abt + RONPOE abt ) + 
qg=.A beB e teT 

E E E • DHCREW abb ' t 

a*A tkr b>b e # cm , teT 

Minimize the sum of: (1) late penalty * number of days late * late cargo delivered directly to the 
line id’s destination, (2) late penalty * number of days late * late cargo shuttled (from the 
transshipment base) to the line id’s destination, (3) late penalty * number of days late * late cargo 
delivered by ground from the transshipment base, (4) nondelivery penalty * undelivered cargo, 
(5) usage penalty * chopped vehicles or reassigned tankers, (6) a small reward (negative penalty) 
* vehicles remaining overnight at an embarkation node (often CONUS, and thereby near home 
station), and (7) crew deadhead penalty * deadheading crews. 

ACBALAPOE: Aircraft Balance at Air Embarkation Nodes (Change from NRMO) 




Z I XT„„ + £ £ XD - 

job reRD b nRD ,a.tm <€/ reRD b C\RD tadtr 



+ S Z XTR + Z Z XDR >. 




+ l(a s A,,,) ■ t TKREC J + RONAPOE, t , = RONAPOE M + 




+ ALLOCACFI + Ha € A, u ) ■ [; TKRCE „,] 



V a € A^, b e B apoe , t e T 
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Aircraft Balance at APOEs: For each aircraft type, APOE, and time period (day); departing 
transshipment missions + departing direct delivery missions + assignments to tanker duty (if 
aircraft is a tanker) + overnight resting aircraft = resting aircraft from yesterday + arriving 
backchannel missions + newly assigned aircraft + reassignments from tanker duty (if aircraft is a 
tanker). Note that direct delivery missions and transshipment missions can be selected to recover 
away from the APOD (XDR, XTR) or recover at the APOD (XD, XT) missions. This is true 
throughout the formulation, except as noted. 



SHBALPOE: Ship Balance at Sea Embarkation Nodes (Change from NRMO) 

Z Z XT * + Z Z + RONPOE m 

^ fob r€RD b ^RD iatnt iel reRD b r\RD iadir 

= ronpoe m + + allocship 

reRB ab 

v a e A ship , b e B poe , t e T 

Ship Balance at SPOEs: Same for ACBALAPOE, but balances numbers of ships at POE’s only. 
Note that ships will not be assigned to tanker duty. 



VBALSUP: Vehicle Balance at SUPER Debarkation Nodes 



z_ y„ + XONT * + THCHOP m = 

reRB^RBrec 

X X X T i.a.r.t-,rv or + X 2 XD ,.a.r.t - ,rv ar + 

iel f0b reRD b nRD, alnt iel reRD b nRDia,dir 

RONT abM + THCHOP abtA + I(t = l) ■ IRON ah 

V a € A, be BS sup , t e T 

Vehicle Balance At Super Nodes: A “super” node is a surrogate for all bases in the theater. 
Flow balance is done with supers, but MOG is constrained at the actual theater POD’s and 
FOB’S. Additionally, this constraint only addresses missions that recover at the POD. Other 
missions are constrained in VBALREC. For each vehicle type, “super”, and time period; the 
departing backchannel missions + ovemightr resting vehicles + total vehicles chopped to the 
theater = arriving transshipment missions + arriving direct delivery missions (for those line id’s 
whose destination is an POD) + last nights resting vehicles + yesterday’s total of chopped 
vehicles + the initial “chops” to theater (if it the first time period). 
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VBALREC: Vehicle Balance at SUPER Debarkation Nodes 



Z r„ 


+ RONR* 


+ THCHOPR ^ 


— 


r ^^ B ab nRB rec 










M 

M 




+ Z 


z 


XDR iarl . lrVa 


ieI /ob reRD b r>RD ialm 




ieJ 


re RD b r\ RD ia j tr 




*onr m + 


THCHOPR a 


bj-\ + 


I(t = l) ■ 


IRONR^ 



V a € A, be BS kc , t e T 

Vehicle balance at super’s using recovery routes: Same as VBALSUP, but balance flow for 
missions not recovering at the POD 



INITRON: allocate initial chops to recovery or not 

IRONT ab + IRONR ab = initchop ab V a e A chp , b e B sup 

Initial RONS in theater: For period 1 and all vehicles and supers; the sum of RONS at POD 
recoveries + RONS at non-POD recoveries = initial aircraft chopped to theater. 



ACFTALLOC: allocate newly available aircraft (Change from NRMO) 

X ALLOC ACFT abt = newv at V a e A ac jj, t & T 

Aircraft allocation: For each aircraft type and time period; the sum of all new allocations to 
APOE’s = the amount newly available. 



SHIPALLOC: allocate newly available ships (Change from NRMO) 

X ALLOCSHIP abt = newv at V a e A sbip , t e T 



Ship Allocation: Same as ACFTALLOC, but for ships only. 
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SHUTLBND: don’t send more tankers than available 



x 



b.sup I fob 



xs. 



lat 



shutrate ia 



< [: THCHOP abt + THCHOPR abt ] 



Vtf € A ac fi , b £ ^sup’ ^ 



Shuttle Bound: For each vehicle type, “super” pod, and time period; the number of round trip 
shuttle missions divided by the daily number of round trip missions per aircraft < total chopped 
vehicles in the theater. 



TKRJBND: don’t use more tankers than available 

E - < TKRB ab , Va e A, kr -, b € B ltr ' ' € T 

b'e BA b>tkr tkrrate abb ' 

Tanker Bound: For all tankers, tanker beddown bases, and time periods; the number of AR 
sorties flown to all tracks divided by the daily sortie rate < tankers assigned to the beddown base. 



CLOUDBAL: flow balance; leaving and entering tanker fleet 



Yjkrec + 'Zjkrbc 

a,b,t-ttrv ab 

beB apoe be B lkr 



Y.TKRCE^, + YJ KRCB .>, 

b ^ B apot b ^ B tkr 



Vtf g A tkr . t £ T 



Tanker Cloud Balance: The “tanker cloud” is an expression for the act of assigning or de- 
assigning multi-role aircraft as dedicated tankers. The “cloud” serves as a control point that 
reduces the number of required assignment and de-assignment variables. For all tanker aircraft 
types and time periods; newly assigned tankers from all APOE’s (adjusted for travel time) + 
newly de-assigned tankers from all tanker beddown bases (adjusted for travel time) = tankers 
returning to all APOEs + tankers deploying to all beddown bases. Note that de-assigning a 
tanker from a beddown base does not force it back to an APOE, it could be re-assigned to 
another beddown base. 
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TKRINVT : tanker inventory at tanker beddowns 



TKRBC^, + TKRB abt = TKRCB ahl + TKRB ah tA Va e A*,, b e B tkr , t e T 

Tanker Inventory: For all tankers aircraft types, tanker beddown bases, and time periods; newly 
de-assigned tankers + total tankers assigned = newly assigned tankers + total tankers assigned 
from last period. 



ARMOG: aerial refueling capacity constraint 



I 2 


Z tkre< J VS ubr ■ XD^ r 


*€/ aeA^ r<zRD b nRD tadir 






* 2 2 


2 


tkreqvs ahr ■ 


XT 

* U'rj-etrv^ r 


/€/ 


- reRD b ^RD ialm 






* 2 2 


2 


tkreqvs Ar 


' XDR i.a,r.,-e,n^ 


ie/ aeArf 


r<=RD b nRD iadtr 






* 2 2 


2 


tkreqvs abr ■ 


' XTR i.a.r.<-e,rv ab , 


ie/ 


r<=RD b nRD iatrn 






2 2 


tkreqvs 


■ Y 

* a. rj-etrv^, 








^ X Z tkr P r °P a bb ■ TKRA abht V b e B arp , t e T 

b'eBTb.'n>aeA, t , 

Air Refueling MOG: Despite the apparent contradiction in terms, this constraint is the air 
refueling analog to airfield MOG. It constrains the capacity of an AR track. For all air refueling 
points and time periods; the fuel required by direct delivery, transshipment, and backchannel 
missions hitting the track in this time period < the amount of fuel available by tanker sorties 
flown to the track. 
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UTE: utilization rate 



X X X X fl ttime arf ■ 

1 €T U iel reRD, ad „ feFT 

♦I I SI ilfc., ■ XT,, 

teT u iel /ot, reRD, atnt feFT 

* I I z I ■ XDR, 

tzT u iel reRD, adtr feFT 

+ Z I E Z ■ XTR . 

/€7; te/ M reRD iatni feFT 

+ Z Z shuttime ia ■ XS ia, + Z Z Z fl ttime arf ' Y a.rj.(f.l) 

iel /ob teT u teT u reRB b feFT 

+ I(a e A lkr ) •[ Z Z Z tkrtime abb- ' TKRA abb .,+ 

beB, kr b'eB arp teT u 

Z Z /2 "i Der • mn; ^ • TKREC ab, + 

b^B a p 0e teT u 

Z Z /zr ^ er * mrV <^ • TKRBC ab, ] 

beB tkr teT u 

< ^ cumac al ■ urate a V a € u e U 

i eT u 



Utilization Rate: Sums all varieties of travel time, so the left-hand side of this constraint 
accumulates travel time only of missions operating during blocks of UTE rate enforcement 
(typically 10-20 day blocks). For each vehicle type and UTE rate block; the travel time of all 
direct, transshipment, shuttle, and backchannel missions (as well as deployed and deploying 
tankers, if appropriate) < total vehicles available * maximum hours per day of average vehicle 
utilization. The/index corresponds to the number of days into a mission, so when/= 1, a 
typical term is the flight time of a mission’s first day * the number of missions (of that type) 
launched that day. Similarly, when/= 2, a typical term corresponds to the flight time of a 
mission’s second day * the number of missions (of that type) launched on the previous day. 
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VCONSUME: max vehicle usage to lessen rounding effects 



Z Z Z msntime arf ■ 

iel reRD iadir feFT 

+ Z Z Z msntime arf ■ XT iart . UA) 

i*l fob re RD, a .i m feFT 

+ Z Z Z msntime arf ■ XDR iarl _ (fA) 

iel reRD iadtr feFT 

+ 2 I I msntime arf • XTR jarl (fA) 

t fob re tm f 6 fT 



hrsper 



+ Y 

.•«/* shut rat e a 



xs ia, + Z Z tnsntime arf ■ Y arJ _ (JA) 



+ I(a € •[ X Z 



rs£B /s/T 

hrsper 



beB tkr b’eB arp tkrrate M . 



tkra ^, + 



Z mrv ai • Griper • TKREC^, + 

beB apa' 

Z r??rV ^ • • TKRBC ab, ] 

^ B ikr 

+ ^ hrsper • RONAPOE abt + ^ hrsper • RONPOE t 

b^ B apae beB ^ 



beB. 



beB^ 



< hrsper • cumac a 



V a e A, t e T 



Vehicles Consumed: Structurally similar to UTE, this constraint reduces the effect of time 
discretization. It supplements the flow balance constraints, which may deal with short missions 
whose rounded duration is 0 periods. For all vehicle types and time periods; mission time of all 
direct, transshipment, shuttle, and backchannel missions (as well as deployed and deploying 
tankers, if appropriate) + resting aircraft < total vehicle hours available. 
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DCAPACITY : direct delivery capacity 



y DTOM^ _| 

cec a ncc parecap l0C 
< £ rangefac iar 

reRD iadir 



paxfrac a ■ DTONS ia 



paxj 



Ha 

maxpax Q 



€ 'VJ 

V i e 1, a e A, t e 



T 



Direct Delivery Mission Capacity: For each line id, vehicle type, and time period; the number of 
tons delivered (summed over cargo classes) divided by the vehicle capacity by cargo type and 
unit + the passengers delivered divided by the passenger capacity < the number of missions 
launched in support of i by vehicle of type a along any route, launched long enough ago so as to 
be arriving at time t. paxfrac specifies the portion of the vehicle filled if fully loaded with 
passengers. Parameter rangefac is frequently 1, but is reduced if the critical leg is long enough to 
exceed the vehicle’s range/payload performance. 



TCAPACITY : transshipment delivery capacity 



TTONS : „ 



+ 



paxfrac a TTONS ia 



paxj 



I(a e A pax ) 



cec„ncc purecap iac maxpax a 

< £ rangefac t iar ■ \xT t a r t . ^ + XDTR i a r Hrv ] V i e I fob , a e A, t e T 



reRD, n 



Transshipment Mission Capacity: Same as DCAPACITY, but applies to missions flown in 
support of cargo and pax deliveries to transshipment POD’s (for subsequent transshipment). 



SCAPACITY: shuttle delivery capacity 

STONSj acl paxfrac a • STONS ,a,pax,t j. . 

2 - + ■ l(a £ A pax ) 

csC a nCC P li recap iac maxpax a 

— srange ia * XSjgi Y / € / , a £ A, t £ T 

Shuttle Mission Capacity: Same as DCAPACITY and TCAPACITY, but applies to intra-theater 
missions moving cargo from transshipment POD’s to FOB’s. 
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DPAXCAP: direct delivery of pax 



DTONS iapaxl < 

X max pax a ■ [xD iawrVr + XDR ^ ^ ] 

r ^ D , a .d,r 



V i e A a e A mix , t e T 



Direct Delivery Mission Pax Capacity: For each line id, vehicle type, and time period; the 
number of pax moved must not exceed the maximum pax per mission * number of missions 
executed. It supplements DCAPACITY, which would (by itself) allow for aircraft to be fully 
loaded with pax, despite available seating configurations. NOTE: DTONS, TTONS, and STONS 
represent number, not tons of pax. 



TPAXCAP: delivery of pax for transshipment 
TTONS, < 

X maxpax „ • + XTR ^ ] Vis/ M ,aeA^,te T 

Transshipment Mission PAX Capacity: Same as DPAXCAP, but applies to transhippment 
missions. 



SPAXCAP: delivery of pax by shuttles 

STONS i a pax t < maxpax a ■ XS ait V / e / fob , a € A mix ,teT 

Shuttle Mission PAX Capacity: Same as DPAXCAP and TPAXCAP, but applies to intra-theater 
shuttle mission. 



MEETDEM: meet demand for each line id 



I I DTONS iact + NOGO ic 
aeA c teT 



+ I (iel f ob )■ 



Z I STONS iact 
aeA c teT 



+ I GTONS ict 

teT 



= dem ic 



V i e /, c e C 



Meet Demand: For each line id and cargo class; direct delivery tons (and pax) moved by all 
vehicles over the available time window + tons moved by shuttle missions (if destination is a 
FOB) + tons moved by ground (if destination is a FOB) + cargo NOT moved = demand by unit 
and cargo class. 
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TRANSTONS: flow balance for transshipped stons 

I TTONS,.,, = X STONS „„ + GTONS, tJ . t ,„ V i s /, c € C. l € T 

aeA c aeA c 



Transshipment Tons: For each line id, cargo class and time period: transshipment tons moved by 
strategic lift = tons moved to FOB by shuttle or ground transport. 



ENITCREWS: initialize crew placement 

7, SCREWS abl + crewrat a ■ ^ TKRB abl = crewrat a ■ newac m V a,t =1 

beB cn ,. beB, kr 

Initialize Crews: For all vehicles and time period 1; strategic lift crews available at all crew 
stage bases + crew contingent for all pre-deployed tankers = number of crews available. 



SCREWBAL: strategic crew balance of flow 
SCREWS = SCREWS abI 



+ I Z_ [ XD 

i€/ reRD iadir r\ R b , 



■C'^abr 



* xdr,.,., k ,„J 
+ X Z _ 1™.. + XD R,...,.«, n „ ] 

fab reR ^ia.tm r ' R b.an 

+ X Y <*<r,t’Ctrv abr “X X _ + XDR i.a.r,.e,rv abr ] 

Rb.an r^RD ta( j tr C\ Rb.dst 

- X X _ [ X7 /.o.r.,.«rv atr + XTR i.a.r.,.e,rv ab , ] 

' e, fab reRD, am r\ Rb.dn 

- X + I (b £ B apoe ) ■ crewrat a ■ VXRCE. - TKREC m ] 

reRBr\ Rb.dst 

+ I(b € B sup ) ■ crewrat a • [THCHOP ab ^ - THCHOP abt + I(t = l) ■ IRONT ah ] 

+ I(b e ) ■ crewrat a ■ \rHCHOPR a b tA - THCHOPR abl + l(t = 1) • IRONR ab ] 
+ /(£> e B e , t ^ 1, newac at > 0 ) ■ crewrat a ■ (ALLOCACFT abl + ALLOCSHIP abt ) 
* £ D HCREW MM „ n - £ DHCREW m , 



b'eB rnL . 



b'eB r , 



V a ^A acfi , b e B crw t e T 



Strategic Crew Balance: For all vehicles, crew stage bases, and time periods; the number of 
crews available tomorrow = number of crews available today + crews coming out of crew rest 
from previous direct, transshipment, and backchannel missions - crews required for departing 
direct, transshipment, and backchannel missions + the net crews made available from tanker 
deployments and returns (if APOE and tanker aircraft) + the net crews made available from 
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“chopped” and “unchopped” vehicles (if “super” POD) + new crew allocations + arriving 
deadhead crews from other bases - deadhead crews departing for other bases. 



MOG: base capacity 
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Maximum On Ground: For all bases (except super pods, AR points, and waypoints) and time 
periods; the vehicle parking (refers also to berthing) required for transiting or terminating direct 
delivery missions + parking for transiting and terminating transshipment missions + shuttle 
mission parking (if FOB or transshipment POD) + chopped vehicle beddown parking (if shuttle 
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beddown base) + divert base parking for failed refuelings of direct delivery, transshipment, and 
backchannel missions + tanker aircraft parking (if tanker aircraft and tanker beddown base) < 
available MOG * MOG efficiency. 

G. VERIFICATION AND VALIDATION 

We did initial validation of NRMOAS using NRMO as the baseline. We constructed a 
small scenario and ran it through both NRMO and NRMOAS. The results were exactly the 
same, so changes made to NRMOAS have not changed the basic functioning of the NRMO 
model. Additionally, we found no mathematical results in the solution file that would indicate 
NRMOAS was behaving in any unrealistic fashion. Ships are allocated only to ports and travel 
only on sea routes, taking the appropriate amount of time to transit and carrying the right 
amount of cargo. We recommend further more stringent validation against other models 
currently in use. In particular, we recommend a comparison with MIDAS as follow on 
research. 
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IV. SCENARIOS 



We ran three similar scenarios through NRMOAS and FDE. Each scenario and the 
results obtained are described in this chapter. Additionally, we ran one scenario through 
NRMOAS both in the user-designating mode and the model-designating mode. These results 
are also compared. 

A. ASSUMPTIONS AND INFORMATION COMMON TO ALL SCENARIOS 

1 . All units can be assumed to make their ALD. 

2. All passengers are moved by aircraft only. 

3. For NRMOAS runs, all bases were given an unlimited supply of fuel. FDE does 
not consider the amount of fuel available on bases as a separate constraint. Also, 
data on fuel availability was generally poor in that most airfields and ports are 
considered to have unlimited fuel capacity. 

4. NRMOAS assigns lift assets to units in order to minimize the weighted sum of 
late and undelivered cargo penalties (Baker, 1997, p. 55). It does not actually 
prioritize units except in the sense that it will assign assets to move a unit with an 
earlier RDD before a unit with a lower RDD. FDE prioritizes units as a function 
of tonnage and the inverse of the square of the unit priority time the RDD (FDE 
URM 1998, p. 3-1): 

unit priority = /{ tonnage , 1 /( priority * RDD) } 

The actual function is not given in the URM and was not available from the 
contractor, so we assumed that setting all unit priorities in IDE to one would 
allow both models to prioritize in the most similar manner. 
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Initial NRMOAS runs were done on a PC with a Pentium Pro processor, a 3.1 
GB hard drive and 32 MB of RAM. Additional runs were done on an IBM 
RS6000 workstation with 1 GB of RAM, and a second PC with a Pentium 13 
Processor and 500 MB of RAM. 

All FDE runs were done on a Sun SPARC Work Station with, 224 MB of 
physical memory and 425 MB of virtual memory. 

All FDE runs used the following parameters: 

a. FDE was only run in simple mode. This is a deterministic mode where input 
values such as speed were fixed at their expected value. No variable inputs 
were used. 

b. Minimizing lateness for units was the only model goal selected. 

c. FDE was told to stop if it reached twenty consecutive infeasible solutions. 
The scenarios run through NRMOAS and FDE were originally designed as 
duplicates. Nevertheless, some network differences occurred due to the data 
input requirements of each program, (described in Chapter IV, Section C). 
Additionally, we noted some discrepancies in unit load requirements in the data 
sets created by other sources. These discrepancies occurred when the FDE data 
files were built separately by a SETA analyst and sent to the Naval Postgraduate 
School for use (see Chapter IV, Section C). We documented the differences for 
each scenario. 

Unit closure is defined as receipt of 100% of all cargo and personnel. 
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B. RESULTS 



1. Scenario # 1 

We designed this scenario to give a baseline for comparison. Movement assets are sufficient to 
meet all RDD’s. It consists of twenty-four units including nine Air Force flying squadrons, 
one Army armored division, one Army mechanized division, one Army air assualt division, 
various Army combat service support units and one USMC regimental landing team. Total 
cargo requirements are shown below in short tons: 



Bulk Cargo: 210293 

Oversized Cargo: 162500 

Outsized Cargo 1 15250 

Pax: 156483 



Lift assets for this scenario are plentiful. The aircraft and ships available are based on 
J8/WAD’s estimates for the total assets that the United States could mobilize in the event of a 



Major Theater War. The assets, as well as their availability dates, are shown below in Table 1. 
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Table 1. This table shows the maximum number of assets that would be available for use 
during an MTW. It includes both military and CRAF air assets, as well as merchant marine 
shipping. Naval and MPS shipping is not considered. Day 1 is the first movement day. NBC, 
WBC and WBP refer to three types of civilian aircraft in the Civil Reserve Aircraft Fleet 
(CRAF). They are, respectively; Narrow Body Cargo, Wide Body Cargo, and Wide Body Pax. 
Ship types are defined in Chapter Three, Section D. 
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Delivery windows ranged from a minimum of 15 days to a maximum of 45 days. Differences 
from NRMOAS to FDE are; NRMOAS used thirteen source nodes while FDE used only six 
and based on differences in data input, FDE was required to move approximately 10% less 
cargo. 

NRMOAS showed no real deviation from the delivery requirements (see Figures 3 and 
4). 99.8% of cargo was delivered on time, as were 100% of personnel. 95.8% of units attained 
cargo closure and 100% attained personnel closure by their RDD (see Figures 7 and 8). 

FDE was unable to meet delivery requirements, needing 16 days beyond the latest RDD 
to deliver all cargo (see Figures 5 and 6). Only 70.1% of units attained closure with cargo by 
their RDD and up to 18 days were required for the last unit to receive all its cargo. Personnel 
deliveries showed similar results, with only 83.3% of units attaining personnel closure by 
RDD. Five days was required for the last unit to receive all its personnel (see Figures 8 and 9). 
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Percent Cargo Delivered - Actual vs. Required 
(NRMOAS Scenario 1) 
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Figures 3 and 4. These graphs show the actual deliveries plotted against the requirements for 
both cargo and personnel. The heavy line represents requirements, while the thin line shows the 
actual deliveries. All cargo was delivered within 45 days and all personnel were delivered 
within 30 days. The large spikes on the required deliveries line are due to scenario design. 

They do not represent an actual TPFDD, but rather a simplified replication developed strictly 
for comparison of the two models. 
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Percent Pax Delivered - Actual vs. Required 
(FDE Scenario 1) 
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Figures 5 and 6. FDE was able to deliver all personnel before the final RDD, but needed 16 
additional days to deliver all cargo. Cargo delivery reached approximately 80% of requirements 
by the last RDD of 45 days. 



52 



Unit Closure - Cargo 
(FDE vs. NRMOAS - Scenario 1 ) 
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Figures 7 and 8. These graphs display the unit closure rates in terms of days after RDD. 
NRMOAS achieved on-time personnel closure for 100% of units and cargo closure for 95.8%. 
In the one case that NRMOAS did not close by RDD, 2 days were required for the unit to close. 
FDE achieved on-time personnel closure for 83.1% of units and on-time cargo closure for 



70.1%. 
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2 . 



Scenario # 2 



We designed this scenario to test the abilities of both programs in terms of achievement 
of delivery windows. Units used and delivery windows are the same as Scenario 1, however 
there was a significant reduction in assets. Assets for this scenario are shown in Table 2: 




Table 2. This table shows the number of assets used for Scenario #2. The number of assets 
eliminated from Scenario 1 is shown in the right column. 



The reduction in assets had a significant affect on NRMOAS’s ability to make 
deliveries on time. NRMOAS required an additional 30 days beyond the last RDD to complete 
delivery of cargo, while an additional 17 days was required for personnel (see Figures 9 and 
10). Unit closure was also affected, with the number of units attaining cargo closure by RDD 
dropping to 29.9% and the number attaining on-time personnel closure dropping to 25% (See 
figures 13 and 14). 

FDE was affected by the reduction in assets to a far greater degree than NRMOAS. 
FDE required 40 additional days beyond the last RDD to complete delivery of cargo and 1 1 
additional days for personnel (see Figures 11 and 12). On-time delivery rates also dropped 
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severely, with just 12.5% of units receiving all their cargo and 20% receiving all their 
personnel by their RDD (see Figures 13 and 14). 






Percent Pax Delivery - Actual vs. Required 
(NRMOAS Scenario 2) 
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Figures 9 and 10. The affects of a 2/3 reduction in lift assets from Scenario lis shown here. 
Actual deliveries were able to stay ahead of required deliveries for cargo up to day 45, the last 
RDD. Although the flow of cargo and personnel remained constant, the slope of the actual 
delivery line indicates a much slower buildup than Scenario 1. 
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Percent Cargo Delivered - Actual vs. Required 

(FDE Scenario 2) 
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Figures 1 1 and 12. The reduction in assets greatly affects FDE’s ability to deliver cargo on 
time. With less than 50% of the cargo required delivered by day 45, FDE required 85 days to 
move all units into theater. Personnel deliveries showed a similar trend, with less than 75% of 
personnel arriving by day 45. 
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Unit Closure - Cargo 
(FDE vs. NRMOAS - Scenario 2) 
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Unit Closure - Pax 
(FDE vs. NRMOAS - Scenario 2) 
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Figures 13 and 14. Asset reduction severely impacted on-time deliveries of both models but 
much more so for FDE. NRMOAS dropped the number of units that received all their cargo by 
RDD to 29.2% and the number that received all personnel by RDD to 25%. The last unit 
required 30 days to attain cargo closure. FDE showed an even more significant reduction in 
cargo closure, dropping to 12.5%. FDE personnel closure dropped to 20.83% 
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3. 



Scenario # 3 



We designed this scenario to test each program using a larger contingency. It consists 
of sixty-one units, and includes one Army armored division, one Army mechanized division, 
three Army mechanized brigades, two Army armored cavalry brigades, one Army armor 
brigade, three Army light infantry brigades, two Ranger regiments, two Special Forces Groups, 
various Army combat support and combat service support units, two USMC regimental landing 
teams, a Maritime Prepositioning Fly-In-Echelon, and twenty-eight Air Force flying squadrons. 
Total cargo requirements are shown below in short tons: 



Bulk Cargo: 417473 

Over Sized Cargo: 277018 

Out Sized Cargo 1733972 

Pax: 315575 



Assets for this scenario are the same as those in Scenario #1 (see Table #1). Delivery 
windows ranged from a minimum of 15 days to a maximum of 45 days. As with Scenarios 1 
and 2, we noted several differences between NRMOAS and FDE’s data. In this case, 
NRMOAS used fifteen source nodes while FDE used only six, and again, based on differences 
in data input, FDE was required to move approximately 14% less cargo and 5% more 
personnel. 

NRMOAS was able to deliver 100% of personnel, but only 94.2% of the cargo (Figures 
15 and 16). The 5.8% nondelivery of cargo is caused by a NRMOAS parameter called 
“maxlate”. “Maxlate” is a user defined parameter that is the maximum number of days after a 
unit’s RDD that cargo and personnel can be delivered. If cargo cannot be delivered by this 
day, it is not delivered at all. “Maxlate” was set to 30 days for this scenario. In this case, the 
unit affected was moved by air, had an RDD of 45 days and received only 52.2% of its cargo. 
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The additional heavy requirements decreased the number of units attaining cargo 
closure by RDD to 72.1% and the number attaining personnel closure by RDD to 67.2% (see 
Figures 19 and 20). 

Although the model parameters were set for 26 trial solutions, FDE repeatedly crashed 
after obtaining only one feasible solution, which is reported here. FDE delivered all required 
cargo and personnel within 65 days. Had a 30 day cut-off restriction similar to NRMOAS’s 
“maxlate” been applied to FDE, cargo deliveries would still have exceeded 99%, while 
personnel would have dropped to 96.8% (see Figure 17 and 18). 96.7% of units achieved 
cargo closure of 30 days, while 80.3% of units attained personnel closure within the same 
period. Of concern, however, are the on-time delivery statistics. Only 48.9% of units cargo 
closed by their RDDs, while only 32% of the personnel closed by their RDD. 
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Percent Cargo Delivery - Actual vs. Required 
(NRMOAS Scenario 3) 
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Figures 15 and 16. Increasing the amount of cargo and personnel to be moved did not greatly 
affect the overall delivery profile. NRMOAS still remained generally ahead of its requirements 
throughout most of the deployment. 100% of personnel were delivered, but only 94.2% of 
cargo. Similar to the delivery requirements in Scenario 1 and 2, the large spikes on the required 
delivery line are a reflection of the simplified TPFDD used in this scenario. 
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Percent Cargo Delivered - Actual vs. Required 

(FDE Scenario 3) 
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Figures 17 and 18. FDE was able to deliver all cargo and personnel to the theater of operations. 
Even the addition of the 30 day cut-off requirement found in NRMOAS would have reduced the 
delivery of cargo by only 0.1% and the delivery of personnel by less than 2%. 
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Unit Closure -Cargo 
(FDE vs. NRMOAS - Scenario 3) 
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Unit Closure - Pax 
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Figures 19 and 20. The large amount of cargo and personnel to be moved in Scenario 3 caused 
NRMOAS to drop the number of units achieving closure by RDD to 72.1% for cargo and 67.2% 
for personnel. In both cases, 90% of the units closed within 2 days of their RDD’s, leaving just 
three units needing to receive deliveries of cargo or personnel. All personnel were delivered 
within 30 days; however, one unit never received its full requirement of cargo because it could 
not be delivered within 30 days of that unit’s RDD. FDE’s unit closure rate also dropped; to 
45.9% for cargo and 37.8% for personnel. Additionally, the final unit to close with cargo 
received its last shipment 42 days past its RDD. Similarly, the final unit to close with personnel 
received it last delivery 32 days after its RDD. IN all scenarios NRMOAS produced more 
favorable closure profiles than FDE. 
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4. NRMOAS Mode Selection Comparison 

As discussed in Chapter III, NRMOAS can be run in two different modes: User 
Select Mode, where the user designates which mode of travel each unit uses, and Model Select 
Mode, where the model designates which mode of travel the unit uses. In addition to the 
comparsion with FDE, we ran Scenario #3 in the NRMOA model select mode. The only 
difference in the scenarios was a slight deviation in RDDs for personnel. Personnel are moved 
only by air; therefore, when using the user select mode, it is necessary to divide those units 
whose cargo moves by sea into two line id’s, one for personnel and one for cargo. In doing 
this, we gave the personnel an earlier RDD. When using the model select mode, it is not 
necessary to split the units, so both cargo and personnel were given the same date. 

The most important result from the two runs is that in the model select mode, 
NRMOAS delivered 100% of cargo amd personnel to the theater of operations, an 
improvement over the 94.3% delivery of cargo in the user select mode. Additionally, while 
on-time delivery rates did not improve greatly, closure rates for both cargo and personnel did. 
(see Figures 21 and 22). 
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Figures 21 and 22. In the model selection mode on-time deliveries for cargo increased from 
72% to 77%. The most noticeable change however, was that all units closed within 19 days. 
On-time delivery of personnel showed a much greater increase, from 67% to 80%. 
Additionally, all personnel closed by day 14, a 14 day decrease from NRMOAS in the user 
select mode. (Note that the graph scales start at 50%.) 
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Figures 23 and 24 show the differences in how cargo was moved. The only major 
difference is in bulk cargo. When NRMOAS selected the mode of movement, significantly 
more bulk cargo was moved by air than by sea. 
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Figures 23 and 24. These figures show the amount of cargo delivered by air and sea under full 
optimization (Model Select mode) and partial optimization (User Select mode). Amounts of 
cargo delivered did not change greatly, with exception of bulk cargo. NRMOAS in model 
select mode found airlift a more effective way to move bulk cargo. Percentages are calculated 
as the percentage of cargo delivered , vice required. This is to account for the undelivered cargo 
from Scenario 3. 

We also discovered a difference in the usage of the Cl 7, WBC and WBP aircraft. In 
the user select mode, unit personnel and cargo were moved as separate line id’s with different 
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RDD’s, normally earlier for the personnel than for the cargo. Because more personnel were 
required to arrive in theater than the use of CRAF assets would allow, the C17 was used to 
move a large amount of personnel instead of cargo. While this is not the preferred use of a 
Cl 7, the model responded in the way it should have, using the best assets available to achieve 
its RDD’s. When used in model select mode, unit personnel and cargo had the same RDD’s, 
which allowed a later arrival time for personnel than from the user select mode scenario. 
Again, the model responded as it should, using the C 17 to carry cargo and saving the personnel 
for the WBP. Thus, the C 17 was used less frequently, but more efficiently in the model select 
mode. The WBC aircraft was also used more frequently by the model select mode, carrying 
bulk cargo that was initially moved by sea. 

C. OVERALL COMPARISONS 

1. Data Preparation 

Data preparation in NRMOAS requires some knowledge of GAMS and its 
requirements for file formatting. GAMS files are written as text files, so once the user is 
comfortable with these aspects of preparation, the process is fairly straightforward. Of the five 
data input files, calc.inc requires no alteration from scenario to scenario. The calculations it 
makes remain the same regardless of scenario specfics. Scenario.inc contains some scenario 
information such as aerial refueling points, tanker beddown points and crew staging bases; 
however, we did not use these factors in the scenarios, so that file also remained unchanged. 
Acdat.inc contains asset specific information and requires an update when the type or 
availability of assets changes. Routes.inc contains network data and therefore must be updated 
with every new scenario. Gamsagg.set also differs for every scenario as it contains all unit 
data, to include load and delivery time windows, and all base data including locations and 



66 



capabilities. NRMO can generate the unit and carrier load information portions of gamsagg.set 
using an Air Force TPFDD and the Air Flow Model (AFM), however the carrier capacity data 
generated in this fashion contains only aircraft data and is not useful to NRMOAS. Instead, 
TPFDD data, as well as aircraft and ship capacity data, must be input by hand. 

For NRMOAS, resolution of TPFDD data can be done to whatever degree the user 
desires. For these scenarios, resolution was down to the squadron level for Air Force units, the 
brigade and division level for Army units and the regimental level for USMC units. Once a 
base file is created, changes can be made fairly rapidly to reflect new scenarios. 

FDE data files are built and edited via the GUI. No preprocessor is available, so 
TPFDD data must be input manually. As with NRMOAS, the level of resolution of the 
TPFDD can be determined by the user; however, most existing FDE units are squadron-, 
brigade- or division-sized. 

FDE GUI is slow and tedious. It requires most entries to be made one at a time and 
does not allow minor changes to be made easily. For example, to reduce the number of C5’s 
available for use on a given day from 56 to 20, the user has two options: either delete 26 C5’s 
one by one, confirming each deletion via a pop-up window; or delete all the C5’s and add back 
in the 20 the user wants. A much simpler method would be to allow the user to highlight and 
delete more than one item at a time. Similar editing options through out all screens make 
creating or changing existing files very slow. 

The most difficult part of building the FDE data file is setting up the network. One 
problem we encountered while building the networks is that paths from a source node to a sink 
node that contain more than four links cause FDE to crash. This severely limits the realistic 
geographical depiction of a deployment network. For example, it is impossible to portray a 
realistic sea route from a seaport in the Gulf of Mexico to the port of Ad Damman, on the east 
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coast of Saudi Arabia with only four links. Additionally, FDE had trouble finding solutions 
when the network was composed of multiple sources with small amounts of cargo. This 
requires that the network be built using a smaller number of aggregate embarkation bases. In 
the case of these comparison scenarios, NRMOAS used 12 or 13 source nodes, while FDE 
used 6. 

In most cases, FDE files are built using the fort. 1 legacy file, which contains extensive 
unit and carrier information. The fort. 1 file serves as a shell from which desired scenarios are 
built. In the absence of the fort.l file, building files can be extremely challenging. In fact, 
building files from scratch is highly discouraged by experienced FDE users. We encountered 
numerous problems during the course of this thesis while building FDE data sets from scratch. 
Eventually, we used data files that were built by a SETA Corporation analyst, using the fort.l 
file. We encountered some discrepancies in the unit load requirements data, which accounted 
for the differences in cargo requirements between the NRMOAS and FDE runs. 

2. Cargo Delivery 

In all but one case, both models were eventually able to deliver all cargo and personnel 
to the theater of operations. The greatest difference between the models was in percentages of 
on-time deliveries. Here, NRMOAS was clearly superior. Overall, high and low on-time 
delivery rates are shown in Figure 25. 
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Figure 25 This graph is a compilation of NRMOAS’s and FDE’s delivery rates over all three 
scenarios. The overall column includes the total number of units delivered on-time over all 
three scenarios. High and low columns indicate the maximum and minimum on-time rates 
achieved. 



While there are may be numerous factors that contribute to the differences in 
NRMOAS’s and FDE’s results, two of the major ones are first, asset utilization rates and 
second, initial allocation methods. Both NRMOAS and FDE require that each lift asset be 
given a utilization rate. This “ute rate”, determines how many hours a day that a certain asset 
can be flown or sailed. Utilization rates used in all three scenarios are shown in Table 3. 



Asset 


C5 


C17 


KC10 


KC135 


NBC 


WBC 


WBP 


Ute Rate 


10.87 


15.15 


12.5 


6 


10 


10 


10 



Table 3. Utilization rates determine the number of hours per day that an aircraft can be flown. 
Ship utilization rates have been omitted, because ships are not subject to crew rest or down time 
when traveling and therefore operate 24 hours a day. NRMOAS uses this data in hours per day, 
whereas FDE converts to fractions of a day. 



NRMOAS sums the number of hours an aircraft is flown and balances it with that 
aircraft’s utilization rate to determine if the aircraft can fly a subsequent mission. Flight times 
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are balanced over a user determined period of time, which we set to 5 days. This allows the 
model a certain amount of flexibility when assigning aircraft to missions. 

FDE takes the same figure, as a fraction of 24 hours. It then multiples this number by 
the total amount of assets available and uses the remaining number of aircraft 24 hours a day. 
This information is not documented anywhere, but was explained by the SETA analyst who 
assited us by building data files. No explanation of how FDE handles ground time was given. 
Based on this reduction method, if there are 56 C5’s available on day one, FDE will only use 
26 of them to account for their utilization rate of 0.4529. FDE always rounds this number up 
so the user never ends up with 0 aircraft due to utilization rate. This method dramatically 
reduces FDE’s available lift assets. Figure 26 shows the differences in aircraft available to 
NRMOAS and FDE. 



Available Aircraft vs. Aircraft Utilized 




■ Available 

□ NRMOAS 

□ FDE 



Figure 26. Due to the way that FDE uses the utilization rate, it effectively starts each 
deployment with one half of the number of aircraft available to NRMOAS. This allows 
NRMOAS to move more cargo faster, making it easier to meet its RDD requirements. Note that 
in the case of the C17 aircraft, FDE did not follow its own algorithm. We could not find a 
reason for this. 
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Another contributing factor in FDE’s difficulties meeting delivery window 
requirements is its allocation algorithm. FDE’s allocation is done as a biased stochastic 
assignment of lift assets directly proportional to the tonnage requirements of the unit and 
inversely proportional to the square of the unit’s priority and its required arrival time (see 
Chaper IV, Section B). Each new trial is a new random number sequence that generates a new 
allocation of lift assets. This heuristic is designed simply to give a feasible starting point. 
(FDE URM, 1998, p. 3-16) A close examination of one unit which arrived on time with 
NRMOAS and 15 days late with FDE shows the flaws in this algorithm. The unit is an Army 
armored division with a RDD of 45 days. Its FDE asset allocation is shown in Table 4: 



Number Allocated 


Asset 


Day Asset Became Available 


1 


WBP 


12 


1 


W BP 


20 


2 


LASH 


15 


1 


RORO 


25 


4 


LM SR 


45 


1 


LASH 


45 


2 


BB 


65 



Table 4. This table shows the allocation of assets to an Army armored division that arrives 15 
days past its RDD (Scenario 1). Because of the random nature of the initial allocation heuristic, 
the unit was not allocated sufficient assets to arrive in theater on time. NRMOAS ‘s solution 
moved the Army division on 7 LMSR’s and 1 1 RORO’s, with closure on day 43. 



Based on lift capabilities and tonnage requirements, the unit did not receive enough 
assets to make its RDD. Because the allocation is based on a random number, this type of 
situation can repeat itself during any trial solution for any type of unit. This would make it 
extremely difficult to determine whether a certain type of unit consistently slows the entire 
deployment, or uses up all of one type of asset. 

Like NRMO, NRMOAS allocates assests based on minimizing the weighted sum of 
late and undelivered cargo penalties, subject to restrictions such as asset balance, asset payload. 
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and port and airfield capacity. In essence, NRMOAS sends the assets to where they will have 
the most positive effect on the overall deployment schedule. In NRMOAS’s case, the Army 
armored division was loaded on 7 LMSR’s and 11 RORO’s, in combination with three other 
units with a similar RDD and destination. It arrived on day 43. Because NRMOAS gives an 
optimal utilization of assets, any shortfalls or slowdowns can be traced to their true cause, 
rather than being due to a poor random draw. 

3. Speed of Computation 

Run time comparisons for the different scenarios are shown in Table 5. 



Scenario 


NRMOAS 
Platform Used 


Run Time 


FDE 

Platform Used 


Run Time 


1 


PC, 32 MB RAM 


38.96 min 


Sun SPAC 


5.34 min 


2 


PC 32 MB RAM 


33.11 min 


Sun SPARC 


71 sec 


3 


PC, 500 MB RAM 


3 hr, 49 min 


Sun SPARC 


61 sec * 




IBM RS6000, 595H 


1 hr, 12 min 






4 


IBM RS6000, 595H 


2 hr, 10 min 


Not Compared 





* Only resulted in one feasible solution before FDE crashed. 



Table 5. The table show the run times for each scenario and what type of platform it was run 
on. For NRMOAS, memory allocation was more of a limiting factor than processor speed. Run 
times for FDE are based on 26 trial solutions except where noted. 



NRMOAS, in searching for an optimal answer, requires significantly greater 
computation time than FDE. The FDE URM states (without proof and without precedent in 
the operations research literature) that if FDE makes between 25 and 75 trial runs, the resulting 
solution will be very close to a global optimum (FDE URM, 1998, p. 3-9). That would 
increase the run times for FDE by approximately three times; however, whenever any number 
of trial runs over 26 was requested, FDE crashed after number 26, requiring us to limit the 
number of trial runs. In the case of Scenario 3 FDE found 1 feasible solution and then crashed 
during trial 2. To avoid crashing, we simply set the number of trial runs to 1 . 
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4. Ease of Analysis of Output 

The NRMOAS output file can be formatted by the user to display whatever data is 
desired. The user can suppress information that is not wanted, as well as display any additional 
information required. The output file gives a detailed breakdown of cargo, carrier, base, route 
and unit information, throughout the course of the deployment. The output file is constructed 
as comma-delimited input to a spreadsheet. This makes the output easy to work with since 
most users should have access to and some knowledge of spreadsheet operations. For 
example, all graphs depicting NRMOAS delivery information were created from the output file 
using Excel© spreadsheet utilities. NRMOAS ’s output report also allows easy infrastructure 
analysis. For example, the user can determine, using the output report, which bases, routes and 
assets were the most heavily used. 

FDE files contain a large amount of information in a series of pre-formatted files (see 
Appendix A for detailed file descriptions). As with NRMOAS, these files give a detailed 
breakdown of cargo movement, carrier assignment, and base and route utilization. They are 
printed as space-delimited text that can be used as standalone reports or imported into 
spreadsheets. FDE also contains files that allow the user to request and view multiple graphs, 
to include model goal satisfaction and percent of units delivered by day. If the user desires 
information in some other format than that which FDE is designed to display, it must be 
created by hand from the output files. As with NRMOAS, this can be done using a standard 
spreadsheet, although a significant amount of data manipulation is required. IDE’s high level 
of aggregation and limited ability to represent actual deployment networks makes it impractical 
to use for detailed infrastructure analysis. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The Force Deployment Estimator is a low resolution model that can be used to give 
quick lower bound solutions to generic force mobility questions. FDE’s usefulness as a tool 
for detailed real world analysis, however, is severely hampered by its inadequete network 
representation. The limitations of at most four links in a path and the high level of aggregation 
required for embarkation nodes, make detailed analysis of actual deployment routes 
impossible.. Exceeding these limitations causes the model to crash. To use FDE, a deployment 
network must be tailored to FDE’s capabilities. This limits FDE’s use to certain “off-the- 
shelf’ scenarios that are known to work. FDE’s high level of aggregation also applies to 
airfield and port services. Fuel capacities are not accounted for and MOG is generally 
unconstrained, assumptions that decrease FDE’s usefulness as a detailed analysis tool. 

When comparing similar scenarios, NRMOAS consistently out-performed FDE, 
achieving superior on-time delivery rates both for cargo and personnel. NRMOAS allows the 
user to input any network or deployment situation and receive an optimal solution and allows a 
high degree of resolution both in network and infrastructure design. This detail makes 
NRMOAS well-suited to in-depth analysis of unit movement, route and base use, and asset 
utilization. NRMOAS ’s solution gives the user the most efficient mix of available assets rind 
routing required to complete a deployment. This allows the user to focus on key areas of 
analysis, without the concern that the results are based on a random allocation. Because 
NRMOAS can be run on any GAMS capable computer, it has a degree of portability that is not 
found with FDE, which is designed to run on SUN SPARC systems. NRMOAS would benefit 
from the inclusion of a more user-friendly interface. Additionally, NRMOAS lack of ability to 
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represent stochastic events could limit its applications in some areas. 



B. RECOMENDATIONS 

If FDE is to be retained as a tool for analysis in J8AVAD, it requires major 
improvements in its ability to accurately represent deployment networks. The current 
limitations of at most four links in a path and FDE’s apparent inability to handle multiple 
source nodes with small amounts of cargo must be corrected for FDE to be at all useful for 
analyzing actual deployment networks. The extreme difficulty in building files from scratch 
must also be corrected. Additionally, the initial allocation alogorithm should be looked at in 
an effort to improve its ability to assign assets. Furthermore, minor improvements to the GUI 
would make it much more tolerable. Finally, unsubstantiated claims of global optimality must 
be retracted. 

NRMOAS’s superior performance in on-time deliveries and higher level of resolution 
for networks and infrastructure make it a better tool for detailed analysis than FDE. J8/WAD 
should utilize NRMOAS for use in answering detailed mobility questions concerning actual 
deployment networks and infrastructure questions. While on-site testing by J8/WAD is 
recommended, we believe that NRMOAS will give J8/WAD an added dimension in mobility 
analysis that it currently does not possess with FDE. 
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APPENDIX A - ADDITIONAL FDE DETAILS 



A. OUTPUT FILES 

1 . “fort.2”, Solution File. This contains a rehash of all input data, a listing of how well FDE 
met its user assigned goals and all of the initial carrier allocation data. It is written in a format to 
allow it to be printed and read as is. (FDE URM, 1998, p.3-25) 

2. “fort.3”, History File. This contains details on all the events that occurred during the 
deployment simulation. It is divided into five sections: 

a. Section 1 contains the date and time the solution was found. 

b. Section 2 contains the path and unit data for link in the route network. 

c. Section 3 lists carrier data and assigns each carrier an index number. It is designed 
for use as a reference. 

d. Section 4 is a state definition table that is also designed for use as a reference. 

e. Section 5 shows the timing for each event that occurs during the simulation. 

(FDE URM, 1998, p. 3-25) 

3. “fort. 10”, Bar Chart Data File. This file holds the data to produce bar charts which can be 
used to display the following information: 

a. A lift objectives chart which shows how close the program came to meeting its 
required goals. 

b. A closure histogram which displays the closure for priority one units 

c. A dispersion histogram which displays the closure of priority one units. 

d. A cost histogram which displays the frequency of costs associated with unit 
movements. 
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e. A re-allocation histogram which shows the re-allocation of units. This chart is only 
available when minimization of re-allocation is selected as a program goal. 
(FDEURM, 1998, p. 3-28) 

4. “fort. 11”, Line Graph Data File. This file contains the data needed to draw line charts. 

These line charts can be used to display the arrival profile of each unit’s cargo and personnel 
over time. (FDE URM, 1998, p. 3-28) 

5. “fort. 12”, Missions on Ground file. The first portion of this file lists the index values of each 
carrier and each node. The rest of the file gives the numbers of each carrier type at each node, 
per unit time. (FDE URM, 1998, p. 3-29) 

6. “fort. 13”, Equipment on Ground File. The first part of the file lists the index values for load 
types, node names and unit names. The rest of the file gives the tons of cargo moved through 
each node, per unit, per unit time. (FDE URM, 1998, p. 3-30) 

7. “fort. 14”, Fraction of Craft Utilized File. This file first lists index values for the carriers. 

The rest of the file gives the number of carriers used by each unit per unit time. (FDE URM, 
1998, p. 3-31) 

8. “fort. 15”, Unit Craft Utilized File. The gives the number of carriers used by each unit per 
unit time. (FDE URM, 1998, p. 3-31) 

9. “fort.16”. Unit Fraction of Actual Craft Utilized File. The first part of this file lists index 
values for the carriers and units. The rest of the file gives the percentage of each type of carrier 
used per unit per unit time. (FDE URM, 1998, p. 3-32) 

10. “fort.75”, Consolidated Graphics File. This is simply a consolidation of files “fort. 12” 
through “fort.16”. This file is no longer needed as a separate file, but is still included in Version 
3.1. (FDEURM, 1998,3-33) 
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B. AIRCRAFT LOADING ALGORITHMS 



The following rules and definitions apply to all algorithms: 

1 . Class 1 carriers carry personnel only - no cargo. 

2. All carriers wait at a node for a full load if the current partial load contains personnel 
only and there are more passengers arriving. The carrier will wait only if waiting will improve 
the closure time of the unit. If waiting will extend the arrival time of the unit, the carrier will 
not wait for the arriving passengers. 

3. All cargo aircraft (Class 2 carriers) can carry bulk cargo. 

4. % Oversized - The proportion of the total cargo weight in short tons which is oversized 
cargo, when the load includes outsized cargo. The percentage is unit specific. 

5. % Outsized - The proportion of the total cargo weight in short tons which is outsized 
cargo, when the load also includes oversized cargo. This percentage is unit specific. 

(FDEURM, 1998, p. 3-16) 

FDE considers five separate loading cases. 

Case 1 : Load consists of bulk, over and out-sized cargo. 

Total Load = carr_over * carr_%over + carryout * carr_%out 

100 100 

Max Outsized Load = carryout * carr_%out 
100 

Max Oversized Load = carr_over * carryover 

100 

Max Bulk Load = Total Load - carr_over - carryout 
Max Passengers = carr_pax 
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Case 2 : Load consists of bulk and out-sized cargo. 

Total Load = carr_out 

Max Outsized Load = carr_out 

Max Bulk Load = Total Load - carr_out already loaded 
Max Passengers = carr pax 



Case 3 : Load consists of bulk and over-sized cargo. 

Total Load = carryover 

Max Outsized Load = carr_over 

Max Bulk Load = Total Load - carryover already loaded 
Max Passengers = carr pax 

Case 4 : Load consists of bulk cargo. 

Total Load = carr_bulk 
Max Bulk Load = Total Load 
Max Passengers = carr_pax 



Case 5 : Load consists only of passengers. The equations used are shown below: 



Max Passengers = carr_paxO 

(FDEURM, 1998, p. D-l) 



The following logic loops are used to determine specific amounts of cargo moved: 
Amount of Outsized Cargo Moved : 



if (min (unit_over, carryover) = 0) , then 
out_moved = min (unit_out , carr_out ) 

else 

over_moved = min (unit_out, carr_%out / 100) 

end if 
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Amount of Oversized Cargo Moved : 



if (min (unit_out, carr_out) = 0), then 

over_moved = min ( uni t_over , car r_over ) 

else 

over_moved = min (unit_over, carr_%over / 100) 

end if 



Amount of Bulk Cargo Moved : 



if (min (unit_out, carr_out) = 0) , then 

if (min (unit_out, carr_out) = 0) , then 

bulk_moved = min (unit_bulk, carr_bulk) 

’ else 

bulk_moved = min (unit_bulk, (carryover- car r_bulk) 

endif 



else 

if (min (unit_out, carr_out) = 0) , then 

bulk_moved = min (unit_bulk, (unit_out, carr_out) ) 

else 



bulk_moved = 



min (unit_bulk, ( (carr-out*carr_%out + 
carr_over*carr_%over) / 100) - 
unit_out - unit_over) 

endif 

endif 



Number of Passegers Moved : 

if (over -moved and out_moved =0 and bulk_moved = 0) , then 
pax = moved = min (unit_pax, carr_pax0) 

else 

pax = moved = min (unit_pax , carr_pax) 

endif 

(FDE URM, 1998, p. D-3) 

C. MODELING ASSUMPTIONS 

1. All arcs are bi-directional. Delivery arcs may be used for re-assignment, but re-assignment 
arcs may not be used for delivery. 

2. Carriers are assigned to unit source nodes. Each carrier will move all of an assigned unit’s 
cargo and personnel before it is re-assigned. 
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3. Carriers that do not allow units to meet their required delivery dates will not be assigned to 
that unit. 

4. Since there are a limited number of carriers that can carry out-sized cargo, they will not be 
assigned to carry sustainment (normally bulk) cargo until all out-sized cargo has been moved. 

5. Carrier re-assignment is based on minimizing the following: 

Q = Active Carriers * Re-allocation Days * (Goal Time - Current Time) * 

Unit Priority / Total Tonnage Left 

6. Personnel only carriers wait at nodes until they are full or no more personnel are enroute to 
that node. 

7. Unit cargo that arrives from different sources can be aggregated upon arrival to a common 
node. 

8. Unit arrival is defined as delivery of 100% of personnel and cargo. 

9. Nodes and links may be degraded by enemy action. 

10. Mine fields do not affect air links. 

1 1. Carriers cannot anticipate when a full node will have space to service them. Therefore, 
loaded carriers at a full node will simply wait until they can be unloaded and empty carriers will 
not go to full a node until it has room. 

12. If the variable input mode is used, all variables are statistically independent. 

(FDE URM, 1998, p. A-l) 
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APPENDIX B - ADDITIONAL NRMO DETAILS 



A. INPUT FILES 

1. Gamsagg.set . Gamsagg.set is designed to work with a pre-processor program, but is also 
fully functional as a stand alone file. The pre-processor takes line information from the TPFDD 
and aircraft capacity data from files contained in the Airlift Flow Model (AFM), the main 
simulation used by the Airlift Mobility Command and combines them into a format usable by 
NRMO. For users with a non-Air Force TPFDD, or users without AFM, the required 
information can be hard wired into gamsagg.set with no degradation of capabilities. For this 
analysis, NRMO was used with hardwired information. Gamsagg.set first lists all aircraft and 
all bases which make up the model. Bases are broken down into embarkation bases, forward 
operating bases, points of departure, enroute bases, aerial refueling points, recovery bases and 
supemodes (aggregate bases). Base locations are input using longitude and latitude. Airfield 
capacity, in terms of Maximum on Ground (MOG) and fuel available are also included. 
Additionally, this file contains all the unit data that would be taken from a TPFDD, to include 
unit identification, point of origin, point of departure, cargo demand available to load date, and 
required delivery date. 

2. Routes.inc . Routes.inc sets up the network over which the deployment is carried out. It 
identifies deployment routes, backchannel (re-deployment) routes and adjacent nodes and arcs. 
In addition, it defines which aircraft can travel over which arcs. This file also is used to 
designate arcs as Category 1, an AMC categorization that is given to flights over water. An 
aircraft flying a Category 1 arc must carry an extra 10% fuel. 

3. Scenario.inc . Scenario. inc contains items specific to a given scenario. This includes the 
breakdown of aerial refueling points, tanker bed down sites, and crew staging bases. It 
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delineates between military and Civil Reserve Air Fleet (CRAF) aircraft. It identifies those 
aircraft that can be refueled by tankers, as well as what aerial refueling points, bed down bases, 
and forward operating bases can be used by which aircraft and which routes. Scenario also sets 
the theater recovery policy; “allrec”, meaning always use recovery routes, “somerec” meaning 
sometimes use recovery routes or “norec” meaning never use recovery routes. Recocery routes 
refer to those routes which contain bases where an aircraft can be serviced after executing a 
quick-turn mission. Recovery policy is set separately for each supor node. Any super node 
containing a port should have a “norec” policy since ships would not be required to execute 
quick turn missions. Scenario.inc contains the data for on load time, off load time and enroute 
recovery and maintenance time. Penalties for late and non-delivered cargo, as well as rewards 
for crew rest are calculated here. In addition, shuttle and aerial refueling parameters are 
contained in this file. 

4. Acdat.inc . Acdat.inc is called by scenario.inc. It contains aircraft specific data, to include; 
relative size (to apply to MOG considerations), speed, allowable utilization rate and the rate at 
which aircraft will be allocated to the deployment. In addition, this file scales the weights of the 
cargo and passengers in order to calculate the aircraft’s “critical” payload at each range. The 
file also includes a fuel consumption table, which contains data for each type of aircraft used. 

5. Calc.inc . Calc.inc is also called by scenario.inc. This file contains many of the calculations 
that are needed elsewhere in NRMO. These calculations include; utilization hours, distances 
and flight times (including ground time), fuel consumption rates and MOG calculations. 
Calc.inc contains an abort function that will abort a mission that cannot be completed within the 
allotted time of the deployment . 
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B. OUTPUT FILE 



The output file is divided into several sections. The first section shows the value of the 
objective function. The next section lists the number of missions flown, by aircraft. The third 
section displays cargo related information. This includes cargo delivered over time by category 
of aircraft (military or CRAF), undelivered cargo and undelivered PAX. The fourth section 
concentrates on information needed for base analysis. It breaks down the number of aircraft per 
day that flow through a base, the fuel and MOG that they use and the cargo that they carry. 
The final section summarizes the total time, flying time and ground time spent on each route. In 
all sections, minimum, maximum and mean values are shown. The report can be tailored to 
display any information desired. 
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APPENDIX C - GLOSSARY OF ACRONYMS / DEFINITIONS 



AFM 


Airlift Flow Model 


AFSAA 


Air Force Studies and Analysis Agency 


AF/XOM 


Air Force Chief of Staff for Mobility 


AMC 


Air Mobility Command 


Bulk 


Cargo with a high weight to volume ratio. Ex: ammunition, 
palletized cargo, batteries, etc. 


carrier 


generic name for any vehicle that conveys cargo or pax 


carr_item 


Indicates carrier capacity of an item. Ex: carr_bulk is how much bulk 
cargo a carrier can move. 


FDE 


Force Deployment Estimator 


GUI 


Graphic User Interface 


item_moved 


Indicates the amount of an item that has been moved. Ex. bulk_moved 
is how much bulk cargo has been moved. 


JCS 


Joint Chiefs of Staff 


MOG 


Maximum on Ground 


MOM 


Mobility Optimization Model 


MRS BURU 


Mobility Requirements Study Bottoms Up Review 


MSC 


Military Sealift Command 


MTW 


Major Theater War 


NPS 


Naval Postgraduate School 


NRMO 


Naval Postgraduate School / RAND Mobility Optimizer 


Over 


Cargo with a low weight to volume ratio. Ex: Trucks, trailers, etc. 


%Over 


Percent of cargo that is oversized. 
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Out 


Cargo that will only fit on ships or wide bodied aircraft. Ex: tank, 
infantry fighting vehicle. 


%Out 


Percent of cargo that is outsized. 


Pax 


Personnel. In FDE, it is the number of personnel that a plane can 
carry while carrying cargo. 


PaxO 


In FDE, the number of personnel a plane can carry if carrying no cargo. 


quick turn 


Unloading an aircraft in theater without servicing. Ships will not execute 
quick turn missions. 


recovery base 


A base where an aircraft can receive services after a quick turn mission 


WAD 


Warfighting Analysis Division 
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